Ứng dụng báo “too many connections”. Bạn tăng pool size hay giảm?

Trực giác sai ở đây đến từ việc nghĩ kết nối là chỗ chứa công việc. Thực ra nó là chỗ chờ. Nếu database xử lý được 20 truy vấn song song với hiệu suất tốt nhất, thì việc để 500 kết nối cùng vào không làm nó nhanh hơn — nó chỉ chuyển hàng đợi từ chỗ bạn kiểm soát được (pool trong ứng dụng) vào chỗ bạn không kiểm soát được (bộ lập lịch của hệ điều hành), nơi mỗi truy vấn giữ khoá và bộ nhớ trong lúc chờ.

Với Postgres còn một chi phí nữa: mỗi kết nối là một tiến trình riêng, tốn vài megabyte và một phần bộ nhớ chia sẻ. Vài trăm kết nối rỗi vẫn ăn RAM đáng lẽ dành cho page cache. Đó là lý do PgBouncer ở chế độ transaction pooling tồn tại — nó cho phép nghìn kết nối phía ứng dụng ánh xạ xuống vài chục kết nối phía server.

Nhưng trước khi chỉnh số, cần hỏi vì sao pool cạn. Rất thường là do transaction giữ quá lâu: một lời gọi HTTP nằm giữa BEGIN và COMMIT, hoặc một job chạy nền dùng chung pool với đường request. Sửa nguyên nhân đó thường làm nhu cầu kết nối giảm một bậc, và không cấu hình nào thay thế được việc đó.

Ở mức senior, câu trả lời đầy đủ có thêm phần tách pool: đường request, job nền và migration nên dùng pool riêng với hạn mức riêng, để một job chạy loạn không nuốt hết kết nối của người dùng thật. Đây là kiểu bulkhead, và nó biến một sự cố toàn hệ thống thành một sự cố cục bộ.