Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjN26-00Dplf-2C for pgsql-general@arkaria.postgresql.org; Fri, 23 Jan 2026 19:41:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vjN23-001E9r-2I for pgsql-general@arkaria.postgresql.org; Fri, 23 Jan 2026 19:41:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjN23-001E9a-0W for pgsql-general@lists.postgresql.org; Fri, 23 Jan 2026 19:41:23 +0000 Received: from mail-yw1-x1130.google.com ([2607:f8b0:4864:20::1130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vjN20-001xKx-2T for pgsql-general@postgresql.org; Fri, 23 Jan 2026 19:41:22 +0000 Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-794341320e2so18957767b3.0 for ; Fri, 23 Jan 2026 11:41:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769197281; cv=none; d=google.com; s=arc-20240605; b=fiBsKWSx5IWLLmqzL8gKXNJ2rJjr7PfAnrVd10RaM7GLDyP+NBVHPCPIM1xKyY/KvB R+XCogF78tWtswTEMcxUnfssY2EtFNlJu6RPiYC0ihXj/HZsphD+Ru4/8BU5eqv4NXXQ 5/sjvbG2WaOyMYG69BYUyuYkiZ5LlBBWYrxXGnZC/XZQgPYJJct4jXwt8bqfGPb8eaPB vZWa2aMyyntVdj0aqaMiHW0Bn1sIC8csAg2D88t6tevoqxciOtKnYn4wJTbtlVZwtPFI tv66REe/8odddXvP5tIrDrnYFWuWb5Vvg3jHUeW2RJy3ySjjEGMx4Srnx0Ah+/fJdPFa s5WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=cJ9BxpDCOWpXNpQDPY/o+82Qb8ekyLzhWo6tiZK6THU=; fh=cQaUnmuwjuR9OsxDL7SxCVBwEjDYlbKL9Ym3U6WPyC4=; b=d6mY7FaXb0OLHpeLGwfNywssfNbyx6S/H/ZpEun2isILRHHvyySXIMtC/akmLFXUyD MiROxO7bvhozJJJQrzE7r7KsRZo/3UcalC3U1tdrHsprgiFoXmaPQiPKcfUTlXgKWJAl j1Llh5l980fYo9tBPLIiRPBneAvGEcm0vx/kvvM3CMdBSvlRf9PI9P1RZdMSxTK4CFOA d6uynzskaKPfvQOeSM0qPKYJpd2QHzTE2IuTMchtBgFUt/HVq5/BOn/rHvIkLJH/MoEh zObUG1Gr0xsWBLTvjtowOKJrQo7Oy+EC9nT0Qdv5jmwm/oNMYbwOdVmYoffVBbS8QeXK aimg==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769197281; x=1769802081; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cJ9BxpDCOWpXNpQDPY/o+82Qb8ekyLzhWo6tiZK6THU=; b=InLSa0Veo2rTrjuxeImlrJJe7Rzla9jg4O6zd8ZZbNPsojhI0CwgYr5boDIJIichvI mFDvs3uANlwbQjuRclfyZOxk78uVHcc32OSUgW3VwVD+790hMwifQMdy7gXNLuyVEUpn 0TYFbbnrML/mdlnJpdMMNgEn4xPJVNkAIM0SyvnCMXP6U5cZyqQIzPc1XGnq4jGk+P41 HdaZnfsyol/p3/2BdSDVXoK4s2U582PBOPiuldY5lM2TkKGKNWScEEWJWlvYXgIzHQB0 zpimlpOKVKawuIZj4JIOprLTuoaf1J4n3Z7lzXi/XTCOAg+DhaMvBz+fwDt8mRzCn1p7 dNXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769197281; x=1769802081; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cJ9BxpDCOWpXNpQDPY/o+82Qb8ekyLzhWo6tiZK6THU=; b=QE+VmWPCIwwbTI+tXzdiKeU+QHmfNEb2lcE/h+71NjqIGXw7cL8drhiuMyfjpjBBDb 2d29dUCXLRt0qULadOYW12cOg3otmFS3Th2PcB6lKDV3NiEl25vgdeQ/yvzH+d3lzHN8 hOr1U9BMGADbltJzM97Pz/wLDEQ2fAUCBU4EfKmV4tuiGLVJ/EisN6YdBRZzhwaqebk0 dvoe1GLdxxo0sDVd76I6TTCoA2o2Ijt2jTrg0uygNzfOkTBcUeEIbX6aGZUV5Ydeqq+T G29zB/3410kmsvRvJg3F1wyY4hpRTcG/HdUGRZO6DnNGkJrnEiwqKfjgoMlHVW4wCVM9 jOzw== X-Gm-Message-State: AOJu0YztWmFru7Ohb2NI3G70GDAcrk5Zfe92JDk2hUm7U5Lfh9UlfFNs wD1cFj9nJ0wUHATXSlpx1C81rdXfHgbZWYcIHuwGitsapRpxI4XEhUyTgFH9tyXpkrXHFoxPyjq skRe1kU3b6lZyTGK8LvSNQLr8uFjhvaGKAXcJ X-Gm-Gg: AZuq6aLCE/UUwRKN/zRu6adYOHkTK9XeVRULAYXxN2vA/WbGbNiGTHf2cGUCOj2sPDB 7ApxpXOMVne/Dn9zWFW6RvQ5BF9iVc4/tzFDWFVaEIniXcfhoiy/1slVMj8+xKRTCN0XvUM5U0x hsqsF+IHC/kmWSvzpz0VQ7GCwKbJr5wf7eOD5NL4q6wkQgxosPA2z00Nrbtj1k2dwvAbF0ng6CZ Xlz+KTTHSzKG+urGqlhE5K6RNkYDElX41oWymhOehz8TWXNTWjYyBYJAXFAwT0BkoTMpEZeg6ay gwkgR7I= X-Received: by 2002:a05:690c:a8e:b0:788:44d:2dca with SMTP id 00721157ae682-79439a1160bmr35243207b3.56.1769197280568; Fri, 23 Jan 2026 11:41:20 -0800 (PST) MIME-Version: 1.0 References: <00fe13de-cbfb-4652-8d62-7b7b15dddd39@aklaver.com> In-Reply-To: <00fe13de-cbfb-4652-8d62-7b7b15dddd39@aklaver.com> From: KK CHN Date: Sat, 24 Jan 2026 01:17:19 +0530 X-Gm-Features: AZwV_Qge1fDj7tQWKkTZoqnCRqcmIvb65Jbtyt-zR9TvIBYTZXYgzps7bwNaxWo Message-ID: Subject: Re: Resource Usage same In spite of fronting my DB server with Pgbouncer ? To: Adrian Klaver Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000722a45064913575a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000722a45064913575a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 24, 2026 at 12:18=E2=80=AFAM Adrian Klaver wrote: > > > On 1/23/26 10:14 AM, KK CHN wrote: > > > > > > > > List, > > I am fronting my postgres 16 server with pgbouncer1.23.1 > > > > What surprises me, even though I am deploying pgbouncer as a separate > > VM in front of DB server VM, the top command shows the almost same > > resource usage statistics in the case of load averages, Memory usage et= c > > on the DB Server, whether I am infronting DB server with pgbouncer or > not. > > > > Please find the top output from the db server pasted here. > > > > https://glot.io/snippets/hf4ilogbz0 > > > > > My Pgbouncer server top output shows littler resource usages in terms > > of CPU, MEM usage > > on the top out put of pgbouncer VM ( load averagaes less than 3 > > always, and Ram usage is very low, swap usage almost nil.. > > > > > > Why eventhough I have deployed pgbouncer for this setup why DB server > > still shows large resource usage as in the pasted out put. > > That would seem logical to me as pgBouncer is just passing the > connections to the Postgres server, the server is doing the heavy > lifting of dealing with statements in the connections. > You mean to say the SQL statements are making this issue ? I also suspected wrongly formed query statements making this much load on the DB server. I also suspect this, as the developers who write queries are not so expertised for writing optimized queries, needs to be addressed separately. How can I find out which query statements are making the DB server on its knees ? Any method to find the bad queries? what parameters/behaviours to be checked for finding those query statements which really makes the db server to its knees by the heavy lifting ? any hints most welcome, I can explore and fix those ones. > > From the top output it looks like you are working with some form of a > EDB product. You need to specify what that product is and it's version. Sorry I missed to mention it, this is an EDB 16 server. Eventhoug I prefer to use any piece of S/W that is FOSS community editions, sometimes it is demanded to manage these products too. > > This list is for the community version of Postgres and people will > assume that is what you are talking about. There are folks that maybe > able to help with EDB versions, but they need to know what it is. > > > > Regards, > > Krishane > > --000000000000722a45064913575a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Jan 24, 2026 at 12:18=E2=80= =AFAM Adrian Klaver <adrian.klaver@aklaver.com> wrote:


On 1/23/26 10:14 AM, KK CHN wrote:
>
>
>
> List,
> I am fronting my postgres 16 server with=C2=A0 pgbouncer1.23.1
>
> What surprises me,=C2=A0 even though I am deploying=C2=A0 pgbouncer as= a separate
> VM in front of DB server VM,=C2=A0 the top command shows the almost sa= me
> resource usage statistics in the case of load averages, Memory usage e= tc
> on the DB Server,=C2=A0 whether I am infronting DB server with pgbounc= er or not.
>
> Please find the top=C2=A0 output from the db server pasted here.
>
> https://glot.io/snippets/hf4ilogbz0 <https:= //glot.io/snippets/hf4ilogbz0>
>
> My Pgbouncer server=C2=A0 top output=C2=A0 shows littler resource usag= es in terms
> of CPU, MEM usage
> on the top out put of=C2=A0 pgbouncer VM ( load averagaes=C2=A0 less t= han 3=C2=A0
> always,=C2=A0 and Ram usage is very low,=C2=A0 swap usage almost nil..=
>
>
> Why eventhough=C2=A0I have deployed=C2=A0 pgbouncer=C2=A0 for this set= up why DB server
> still shows large resource usage as in the pasted out put.

That would seem logical to me as pgBouncer is just passing the
connections to the Postgres server, the server is doing the heavy
lifting of dealing with statements in the connections.
=C2=A0
You mean to say the SQL statements are making this issue = ?=C2=A0 I also suspected wrongly formed query statements making this much l= oad on the DB server.=C2=A0=C2=A0
=C2=A0I also suspect this,=C2= =A0 as the developers who write queries are not so expertised for writing o= ptimized queries, needs to be addressed separately.=C2=A0

How can I find out which query statements are making the DB server = on its knees ?=C2=A0 Any method to find the bad queries? what parameters/be= haviours to be checked for finding those query statements which really make= s the db=C2=A0server to its=C2=A0knees=C2=A0 by the heavy lifting ?=C2=A0 = =C2=A0any hints most welcome, I can explore and fix those ones.=C2=A0
=
=C2=A0

=C2=A0From the top output it looks like you are working with some form of a=
EDB product. You need to specify what that product is and it's version.=
=C2=A0
Sorry I missed to mention it, this is an EDB = 16 server.=C2=A0 =C2=A0Eventhoug=C2=A0I prefer to use any=C2=A0piece of S/W= that is FOSS community editions, sometimes it is demanded to manage these = products=C2=A0 too.=C2=A0 =C2=A0
=C2=A0

This list is for the community version of Postgres and people will
assume that is what you are talking about. There are folks that maybe
able to help with EDB versions, but they need to know what it is.


> Regards,
> Krishane

--000000000000722a45064913575a--