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.
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
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
