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 1vitoN-000z40-2C for pgsql-general@arkaria.postgresql.org; Thu, 22 Jan 2026 12:29:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vitoL-00CxUR-1g for pgsql-general@arkaria.postgresql.org; Thu, 22 Jan 2026 12:29:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vitoL-00CxUJ-0T for pgsql-general@lists.postgresql.org; Thu, 22 Jan 2026 12:29:17 +0000 Received: from mail-yw1-x1129.google.com ([2607:f8b0:4864:20::1129]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vitoI-001twp-2z for pgsql-general@postgresql.org; Thu, 22 Jan 2026 12:29:16 +0000 Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-78fb5764382so9373217b3.0 for ; Thu, 22 Jan 2026 04:29:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769084953; cv=none; d=google.com; s=arc-20240605; b=V4zVS5qRCc7rtbwwd9c9qnpnfQyBHtjVVCNB+dm7nOKmbnfIfJdh2K9JLHgCAUeBIc OsYYpOFDGbihSJl5UFmHFzxQV9yc6YzEG5v+0VJBBwgTkXu7ZRqCHsUbgSAIZ8LDHZgj 8+6u+xuQn5bKuvk60bBgIZ+4sg4JwVWiH3JK20EuO+LkrLZIGAyevc44ICOjmQRiPP2P qEyRULw37ZQ47mX2FKzYRfQh6wqt3PT7zvxy4J/KhejGxqXoCil5skqMQr5AuWXzwBeG R0q+kx7A/XClxoMEy0Dsk5iY6VXpH1EtkSLsu2igCv17j5VzGEKmZp2+lcouWmx6xmaI F4ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=YSPAoB5UsIDJuvLyI9jTdZpvdAwHmwyx2EWbIJNUNOk=; fh=KNSq+t9BltSXFnT3Yof/aKGBtqxeA+bTALiYdvTslaY=; b=ZnGdJ/P924Tyc6UCvfaG0rahCRDZFr6eFa2w+c02WdLAc4FAEok+r0Dmx/7RAGkcEd Yowy56CFxi2wCNU/smTeJkdy/3d9u63OGy+BpZD2msiFj2/wUK58kOkQu3kiz5O2GznG eF83F0PWkyVHIxdLGFgnCiRGbYOsfEr1/CfoZGQFKe76c3acqm9aPGuQ/EmvuDU3NakW rOuugdmP3SS2VbyDeO5deM9Cx0i8pD15fiTu2oFbAcW1chezoFy90wHXV6Or2GxViwoD 7NMKKeI3k7oMBv8DkAuieAPxrhCfNNNGNU4JiBIgWlxXY8ex386wg7sZi83j1NtALqpK O2zA==; 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=1769084953; x=1769689753; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=YSPAoB5UsIDJuvLyI9jTdZpvdAwHmwyx2EWbIJNUNOk=; b=nmAOG55v0dX+cgxhmWy3yZiRbr6sPa8zaiOGJlOnD7i9mUFG/q3tC5sUYfcNdRNbzI PjiHzDLgiwTJIxW/8CnYNKigBsIEZ8uWrrN7mN/5aM8uRKR7VnQLoaCsteCCtKYvrSRc QUq9kLbVT7/a2obA1yvuRyvVuAG0U38RWYPp++No/2nbuMoVIEu1K2EFgv/iHHoT6l+M vQ8YrDWmmVy7+ZBdry+DECm6BmVOuuaZ/yZxcy0G4EBF5O9wGRXUU2Na0OWO5m/2Fjnl 5C6PcT6qpljTNdk+bOJPy+oEgLjBBR496xx2zhWLCGSXXoPIChMhF7mmiUKS5U8GdCpS awzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769084953; x=1769689753; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YSPAoB5UsIDJuvLyI9jTdZpvdAwHmwyx2EWbIJNUNOk=; b=a+B157u4yRXYEaCKj7X3zhTEAmLjfGJwKDLCNALCt5omwb3S0E/VZo+ixzWV5yHCeB txplIQ6EH+JjTFQ+k09wgYRi0h0Xb3e3l+lRssyk802ntjF4m+bvFBqAzR9zdnkQRQhZ sdW1HId0t/W9whau0MTLQA5N/YPxEbNrETS+M/1m+mr8WMxdDe2xtZVxotBAB13RJmnU Tt/N4QYOMx8TFNVzej+C1LrqlYSQcSzRymm27FdMYQs+auv79bzkE+T1gK2RR5iUF0Qn 46Ueu9i/cB5a+aGjMnEfIaikYiWXRawRjIh1g3YZiYM/aKGLBycO3H7Re0YqYkOB6Oxn jG/A== X-Gm-Message-State: AOJu0YxvQZ22MtVZINhgeNAjVxB/dNSYYlnwn9PqraTLdZuVEtsOsD2K MGel++SS6jloRsXZxJ1sOMWC0Qb7zlUbWK0czlCLcNO48GbHxl5SDV7dhx4xVJ5zxAzTAa+XNLs urAlLmpA4L0X1Sd+Z38cxiRGdrJDegEYOveN7 X-Gm-Gg: AZuq6aJAyf25K0b4nVwqLhxF/fQ4p/hw3D7bgQ912wfkgkhB0ufZ7DiH67knwOSdJ8S hiXnLQ4adYcNToeWCcwZh86NvOwzFHiNcwQr3UwQRbF41o/XyhWcGlTG0eeVO1baLRTCNPSCu/w gW8ZRg/aBs2cwcfWiGhlHLrIFl9UjDuOW1xH65u9sSoRfltkYUAN67EHZ/mgf1HPy2lUmjAZM2K siCBiEhue+vcwKzjvfd7nXXwmf6Is9dOdODkv7GHUFr+ZY0mrqlsIZdZIA+5d7xIsd/whcB X-Received: by 2002:a05:690c:d85:b0:794:2ea0:e48c with SMTP id 00721157ae682-7942ea0efe6mr10761797b3.47.1769084952328; Thu, 22 Jan 2026 04:29:12 -0800 (PST) MIME-Version: 1.0 From: KK CHN Date: Thu, 22 Jan 2026 18:05:12 +0530 X-Gm-Features: AZwV_QiJJ6DgOWvrVF0ZHKtv97mL4AF0g6AqajmYe1rqR2bVk9gy83AEeIH41Fg Message-ID: Subject: Pgbouncer performance query To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000293f600648f9304d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000293f600648f9304d Content-Type: text/plain; charset="UTF-8" List, I am trying pgbouncer for inhouse deployment for PostgreSQL 16. My setup is PostgreSQL VM : 5444 <=> Pgbouncer VM:5444 <===> Clients (PostgreSQL with IP 10.12.0.2 and Pgbouncer 10.12.0.35 ) Conducted an inhouse benchmark test (pgbench) performed, I have seen the following results. On direct hit the DB server handled tps = 162252.508744 (without initial connection time) latency average = 1.233 ms (Total time taken around 2 Minutes to complete) Through Pgbouncer it handled tps = 25107.166425 only ( without initial connection time) latency average = 11.949 ms ( Total time taken around 20 Minutes to complete ) Could someone shed some light on improving the total time taken by pgbouncer in this scenario ? How can I improve the total time taken from 20 Minutes to any reasonably good value, say 5 Minutes is it possible ? I agree when I have increased the concurrent connections to 300 (pgbench -c 300 ) then Direct hit on DB server fails with Error too many clients as follows [root@pgbouncer ~]# pgbench -c 300 -j 2 -t 100000 -h 10.12.0.2 -p 5444 -U recoil -S recoil Password: pgbench (16.9, server 16.3.0) starting vacuum...end. pgbench: error: connection to server at "10.12.0.2", port 5444 failed: FATAL: sorry, too many clients already pgbench: error: could not create connection for client 134 [root@pgbouncer ~]# I have followed this link for benchmark tests ( https://www.thediscoblog.com/supercharging-postgres-with-pgbouncer) on Direct hit on DB Server without pgbouncer RESULTS: [root@pgbouncer ~]# pgbench -c 200 -j 2 -t 100000 -h 10.12.0.2 -p 5444 -U recoil -S recoil Password: pgbench (16.9, server 16.3.0) starting vacuum...end. transaction type: scaling factor: 500 query mode: simple number of clients: 200 number of threads: 2 maximum number of tries: 1 number of transactions per client: 100000 number of transactions actually processed: 20000000/20000000 number of failed transactions: 0 (0.000%) latency average = 1.233 ms initial connection time = 1549.421 ms tps = 162252.508744 (without initial connection time) [root@pgbouncer ~]# *Through Pgbouncer to DB Server* [root@pgbouncer ~]# pgbench -c 300 -j 2 -t 100000 -h localhost -p 5444 -U recoil -S recoil Password: pgbench (16.9, server 16.3.0) starting vacuum...end. transaction type: scaling factor: 500 query mode: simple number of clients: 300 number of threads: 2 maximum number of tries: 1 number of transactions per client: 100000 number of transactions actually processed: 30000000/30000000 number of failed transactions: 0 (0.000%) latency average = 11.949 ms initial connection time = 26.699 ms tps = 25107.166425 (without initial connection time) [root@pgbouncer ~]# date Thu Jan 22 22:13:46 IST 2026 [root@pgbouncer ~]# *But this takes around 20 Minutes to finish. Is this usual behavior ? * my DB VM(RHEL9.4) is 16vCPU, 16GB RAM and Pgbouncer VM(FreeBSD 14.3) is 8 vCPU and Ram is [root@pgbouncer ~]# sysctl -h hw.physmem hw.physmem: 17143681024 [root@pgbouncer ~]# TOP usage statistics of pgbouncer vm with 200 clients last pid: 10020; load averages: 1.23, 0.83, 0.59 up 187+22:53:33 22:59:41 27 processes: 1 running, 20 sleeping, 6 stopped CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 79M Active, 1063M Inact, 1410M Wired, 1030M Buf, 13G Free Swap: 7068M Total, 7068M Free *pgbouncer.ini * [root@pgbouncer ~]# grep ^[^\;\;] /usr/local/etc/pgbouncer.ini [databases] recoil = host=dbmain.mydomain.in port=5444 dbname=recoil [users] [pgbouncer] logfile = /var/log/pgbouncer/pgbouncer.log pidfile = /var/run/pgbouncer/pgbouncer.pid listen_addr = * listen_port = 5444 auth_type = md5 auth_file = /usr/local/etc/pgbouncer.users admin_users = myuser stats_users = myuser, pool_mode = transaction // *Is this the pool_mode * *I have to use *? max_prepared_statements = 100 server_reset_query = DISCARD ALL server_reset_query_always = 1 ignore_startup_parameters = extra_float_digits, options, statement_timeout, idle_in_transaction_session_timeout max_client_conn = 5000 default_pool_size = 40 min_pool_size = 20 reserve_pool_size = 10 reserve_pool_timeout = 5 max_db_connections = 900 max_user_connections = 800 server_lifetime = 3600 server_idle_timeout = 60000 [root@pgbouncer ~]# *Any parameters do I need to adjust for better performance in terms of latency time improvement, kindly guide me* Best regards, Krishane --000000000000293f600648f9304d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
List,=C2=A0

I am trying pgbouncer=C2=A0= for inhouse deployment for PostgreSQL 16.

My setu= p is=C2=A0 =C2=A0 =C2=A0 PostgreSQL VM : 5444=C2=A0<=3D> Pgbouncer VM= :5444=C2=A0 <=3D=3D=3D> Clients
(PostgreSQL with IP 10.12.0= .2=C2=A0 and=C2=A0 Pgbouncer 10.12.0.35 )

Conducte= d an inhouse=C2=A0=C2=A0benchmark=C2=A0 test (pgbench) performed,=C2=A0 =C2= =A0I have seen the following results.=C2=A0=C2=A0

= On direct hit=C2=A0 the DB server=C2=A0 handled tps =3D 162252.508744 (with= out initial connection time)=C2=A0
latency average =3D 1.233 ms= =C2=A0 (Total time taken around=C2=A0 2 Minutes=C2=A0 to complete)=C2=A0
=C2=A0=C2=A0
Through Pgbouncer=C2=A0 it handled=C2=A0= tps =3D 25107.166425 only=C2=A0 ( without=C2=A0initial=C2=A0connection tim= e)
latency average =3D 11.949 ms=C2=A0 =C2=A0( Total time taken a= round 20 Minutes to complete )

Could someone s= hed some light on=C2=A0 =C2=A0improving the total time taken by pgbouncer i= n this scenario ?=C2=A0 =C2=A0 =C2=A0How=C2=A0can I improve the=C2=A0 total= time taken=C2=A0 from 20 Minutes to any reasonably good value, say 5 Minut= es is it possible=C2=A0 ?


I agree= =C2=A0 when I have increased the concurrent connections to 300=C2=A0 =C2=A0= (pgbench=C2=A0-c 300 ) then=C2=A0 Direct hit on DB server fails with=C2=A0 = Error too many clients as follows

[root@pgbouncer = ~]# pgbench -c 300 =C2=A0-j 2 -t 100000 -h =C2=A010.12.0.2 =C2=A0-p 5444 -U= recoil -S recoil
Password:
pgbench (16.9, server 16.3.0)
starting= vacuum...end.
pgbench: error: connection to server at "10.12.0.2&q= uot;, port 5444 failed: FATAL: =C2=A0sorry, too many clients already
pgb= ench: error: could not create connection for client 134
[root@pgbouncer = ~]#



I have followed = this link for benchmark tests ( https://www.thediscoblog.com/supercharg= ing-postgres-with-pgbouncer)

on Direct hit on = DB Server without=C2=A0 =C2=A0 pgbouncer=C2=A0 =C2=A0 =C2=A0 =C2=A0RESULTS:= =C2=A0

[root@pgbouncer ~]# pgbench -c 200 =C2=A0-j= 2 -t 100000 -h =C2=A010.12.0.2 -p 5444 -U recoil -S recoil
Password:pgbench (16.9, server 16.3.0)
starting vacuum...end.
transaction typ= e: <builtin: select only>
scaling factor: 500
query mode: simpl= e
number of clients: 200
number of threads: 2
maximum number of tr= ies: 1
number of transactions per client: 100000
number of transactio= ns actually processed: 20000000/20000000
number of failed transactions: = 0 (0.000%)
latency average =3D 1.233 ms
initial connection time =3D 1= 549.421 ms
tps =3D 162252.508744 (without initial connection time)
[r= oot@pgbouncer ~]#=C2=A0 =C2=A0=C2=A0



Through=C2=A0 Pgbouncer=C2=A0 =C2=A0 to DB Server


= [root@pgbouncer ~]# pgbench -c 300 =C2=A0-j 2 -t 100000 -h localhost -p 544= 4 -U recoil -S recoil
Password:
pgbench (16.9, server 16.3.0)
star= ting vacuum...end.
transaction type: <builtin: select only>
sca= ling factor: 500
query mode: simple
number of clients: 300
number = of threads: 2
maximum number of tries: 1
number of transactions per c= lient: 100000
number of transactions actually processed: 30000000/300000= 00
number of failed transactions: 0 (0.000%)
latency average =3D 11.9= 49 ms
initial connection time =3D 26.699 ms
tps =3D 25107.166425 (wit= hout initial connection time)
[root@pgbouncer ~]# date
Thu Jan 22 22:= 13:46 IST 2026
[root@pgbouncer ~]#

But t= his takes=C2=A0 around=C2=A0 20 Minutes to finish. Is this=C2=A0 usual beha= vior ?=C2=A0 =C2=A0=C2=A0

my DB VM(RHEL9.4)=C2= =A0 is=C2=A0 16vCPU,=C2=A0 16GB RAM=C2=A0 and=C2=A0

=C2=A0Pgbouncer VM(FreeBSD 14.3)=C2=A0 is=C2=A0 8 vCPU and Ram is [root@p= gbouncer ~]# sysctl -h hw.physmem
hw.physmem: 17143681024
[root@pgb= ouncer ~]#

TOP usage statistics of pgbouncer vm wi= th=C2=A0 200=C2=A0 clients=C2=A0 =C2=A0

last pid: = 10020; =C2=A0load averages: =C2=A01.23, =C2=A00.83, =C2=A00.59 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 up 187+22:53= :33 22:59:41
27 processes: =C2=A01 running, 20 sleeping, 6 stopped
CP= U: =C2=A00.0% user, =C2=A00.0% nice, =C2=A00.0% system, =C2=A00.0% interrup= t, =C2=A0100% idle
Mem: 79M Active, 1063M Inact, 1410M Wired, 1030M Buf,= 13G Free
Swap: 7068M Total, 7068M Free

pgbouncer.ini=C2=A0 =C2=A0
[root@pgbouncer ~]# grep = ^[^\;\;] /usr/local/etc/pgbouncer.ini
[databases]
recoil =3D host=3D<= a href=3D"http://dbmain.mydomain.in">dbmain.mydomain.in port=3D5444 dbn= ame=3Drecoil
[users]
[pgbouncer]
logfile =3D /var/log/pgbouncer/pg= bouncer.log
pidfile =3D /var/run/pgbouncer/pgbouncer.pid
listen_addr = =3D *
listen_port =3D 5444
auth_type =3D md5
auth_file =3D /usr/lo= cal/etc/pgbouncer.users
admin_users =3D myuser
stats_users =3D myuser= ,
pool_mode =3D transaction=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is this the= pool_mode=C2=A0 I have to use ?
max_prepared_statements =3D = 100
server_reset_query =3D DISCARD ALL
server_reset_query_always =3D = 1
ignore_startup_parameters =3D extra_float_digits, options, statement_t= imeout, idle_in_transaction_session_timeout

max_client_conn =3D 5000=
default_pool_size =3D 40
min_pool_size =3D =C2=A020
reserve_pool_= size =3D 10
reserve_pool_timeout =3D 5
max_db_connections =3D 900
= max_user_connections =3D 800
server_lifetime =3D 3600
server_idle_tim= eout =3D 60000
[root@pgbouncer ~]#=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0Any=C2=A0 parameters do I need to=C2=A0 adju= st for better performance in terms of=C2=A0 latency=C2=A0 time improvement,= =C2=A0 kindly guide me


Best regards,
Krishane=C2=A0


<= /div>


--000000000000293f600648f9304d--