Connection Pooling & Thread Tuning Lab (Interactive)
Sweep query rate, latency, cores, and pool size to find the (2×C)+1 sweet spot before context-switch thrash bites. Compute L = λW concurrency demand, wasted kernel cycles, and backend process RAM while toggling PgBouncer transaction pooling.
Little's Law Connection Pool Tuner
More connections make the database slower — find the (2×C)+1 sweet spot.
How It Works Under the Hood
PostgreSQL forks a 5-10 MB backend process per connection, so 2,000 clients on 8 cores leave the kernel spending most CPU saving and restoring registers instead of running SQL. Benchmarks converge on Max Connections = (2 × cores) + spindles — about 17-20 for a typical box — and Little's Law (L = λW) proves it: 10,000 queries/sec at 2 ms each need exactly 20 in-flight connections. PgBouncer transaction pooling multiplexes thousands of pod clients over that lean pool by binding a physical connection only for BEGIN..COMMIT.
Core Architectural Principles
- L = λ × W: 10,000 QPS × 2 ms = 20 concurrent connections; any more is queuing, not throughput.
- Oversized pools invert performance through context switches, page-table swaps, and buffer-cache lock convoys.
- Thread pools size as cores+1 for CPU-bound work and cores × (1 + wait/service) for I/O-bound work with bounded queues.
Quote the formula and the law: "Pool size (2 × cores) + 1, and Little's Law says 10k QPS at 2 ms needs 20 connections." Then name PgBouncer transaction pooling for 200-pod Kubernetes fleets and flag its session-state caveat. Unbounded queues get you the OOM killer — saying that prevents a follow-up question.
Pools too large thrash the kernel and exhaust RAM; pools smaller than λW starve app threads waiting on connections — both failure modes need the same math to spot.