Process thrashing occurs when excessive PostgreSQL concurrency leaves processes with tiny execution slices. The server spends more time switching between backends than executing useful work. section 6.3
PostgreSQL uses a process-per-user model: each client connects to a backend, coordinated by the postmaster through semaphores and shared memory. Too many backends add operating-system overhead, CPU context switching, and potentially swap activity. section 6.3
The tempting concurrency increase
A 2,000-client pgbench run achieved only 352.1 TPS with 5,535 ms average latency, while 250 clients achieved 635.7 TPS with 393 ms latency. Throttle concurrency or add application-side latency so queries run on a less overloaded server. section 6.3
pgbench -U postgres -h test01 -c 2000 -j 24 -T 300 pgbench pgbench (17.0 (Ubuntu 17.0-1.pgdg24.04+1)) starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1000 query mode: simple number of clients: 2000 number of threads: 24 maximum number of tries: 1 duration: 300 s number of transactions actually processed: 84835 number of failed transactions: 0 (0.000%) latency average = 5535.267 ms latency stddev = 13696.921 ms initial connection time = 69772.527 ms tps = 352.083626 (without initial connection time)
Inspect the high-concurrency pgbench command and its measured transaction rate, latency, and connection cost. section 6.3
