Re: Pgbouncer performance query - Mailing list pgsql-general
| From | KK CHN |
|---|---|
| Subject | Re: Pgbouncer performance query |
| Date | |
| Msg-id | CAKgGyB8v1-EU-u+BVR=DqfZyEoa2doZvDG7O5gd77MOWN-hs7Q@mail.gmail.com Whole thread Raw |
| In response to | Re: Pgbouncer performance query (Dominique Devienne <ddevienne@gmail.com>) |
| List | pgsql-general |
My query is on the latency average = 11.949 ms (with Pgbouncer ), at the same time direct hit on Database server latency average = 1.233 ms (Without pgbouncer) Is this an expected usual behaviour when you employ pgbouncer ?
NOTE: Both pgbench tests hit the database server with pgbouncer and without pgbouncer performed from the pgbouncer virtual machine tty only not from the database server tty. So how does pgbouncer running as a separate VM affect the latency part ?
Or is this due to pgbouncer as a separate VM I was running in front of the database server ? Somewhere I have referenced it is better to run pgbouncer on a separate instance to avoid the overhead of the pgbouncer process on the database server (?)
Or as Adrian Klaver suggested, the best solution is to run the pgbouncer on the same database server.
What do others suggest ?
Just increase max_connections then:
https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNECTIONS
Already max_connections = 500 in the postgresql.conf You suggest to increase it to further ( 1000 ?)
Please find the postgresql.conf important params here ( Any thing to fine tune ? )
listen_addresses = '*' # what IP address(es) to listen on;
port = 5444 # (change requires restart)
max_connections = 500 # (change requires restart)
shared_buffers = 128MB # min 128kB
dynamic_shared_memory_type = posix # the default is usually the first option
max_wal_size = 1GB
min_wal_size = 80MB
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = '$libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,pg_stat_statements'
edb_dynatune = 66 # percentage of server resources
edb_dynatune_profile = oltp # workload profile for tuning.
timed_statistics = off # record wait timings, defaults to on
Regards,
Krishane
On Thu, Jan 22, 2026 at 6:05 PM Dominique Devienne <ddevienne@gmail.com> wrote:
On Thu, Jan 22, 2026 at 1:29 PM KK CHN <kkchn.in@gmail.com> wrote:
> 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
Just increase max_connections then:
https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-MAX-CONNECTIONS
Sounds like you should stick to direct PostgeSQL access, if pgBouncer
makes it 10x slower :). --DD
pgsql-general by date: