Nguồn: PlanetScale Blog
Tóm tắt
Postgres sử dụng mô hình process-based: mỗi client connection spawns một backend process mới, tiêu tốn 5-10MB RAM, CPU cho context switching, và file descriptors. Khi connection count tăng, memory pressure và context switching overhead khiến query throughput giảm và latency tăng. max_connections mặc định là 100 — đây là ngưỡng giới hạn cứng của Postgres.
PgBouncer (ra mắt 2007) là connection pooler phổ biến nhất giải quyết vấn đề này: clients kết nối vào PgBouncer thay vì trực tiếp vào Postgres, và PgBouncer duy trì một pool nhỏ các kết nối thực sự đến database, multiplexing requests từ nhiều clients qua số lượng connections ít hơn. PgBouncer hỗ trợ ba pooling modes: session pooling (server connection duy trì suốt session của client, ít efficient nhất), transaction pooling (server connection chỉ được giữ trong duration của một transaction — mode phổ biến nhất trong production), và statement pooling (efficient nhất nhưng không hỗ trợ multi-statement transactions).
Cấu hình PgBouncer cơ bản yêu cầu pool_mode, max_client_conn (số lượng client connections PgBouncer accept) và default_pool_size (số lượng Postgres connections thực sự trong pool). Trong production, max_client_conn có thể đặt lên 10000 trong khi default_pool_size chỉ cần 20-50 — tỉ lệ multiplexing 200-500x. Authentication có thể dùng auth_type = md5 hoặc scram-sha-256, với credentials trong file userlist.txt.
Monitoring PgBouncer thông qua admin console (psql -p 6432 pgbouncer) với các queries như SHOW STATS và SHOW POOLS cho phép theo dõi cl_waiting (clients đang chờ pool connection), sv_used (server connections đang được sử dụng), và pool utilization. Khi cl_waiting tăng cao, đây là tín hiệu cần tăng default_pool_size hoặc tối ưu query duration.