PostgreSQL connection pool: giới hạn và tránh nghẽn

Connection pool tái sử dụng kết nối database để giảm tạo kết nối lặp và kiểm soát concurrency. Nó không tự tối ưu truy vấn. Nếu tổng pool của mọi instance vượt giới hạn database, thêm máy ứng dụng có thể làm lỗi kết nối tăng.

Connection không phải request hay query

Đo cả thời gian chờ pool và thời gian query. Request chậm vì pool chờ khác truy vấn chậm do lock/I/O. Giới hạn kết nối phải phối hợp với khả năng xử lý và bộ nhớ server.

Cộng pool của toàn hệ thống

Giả sử mỗi process có pool tối đa 10 connection, ứng dụng có 3 instance và mỗi instance 2 process. Tổng lý thuyết là 10 × 3 × 2 = 60 connection, trước worker, migration, monitoring và truy cập quản trị. Đây là ví dụ kiến trúc; cách pool hoạt động phụ thuộc driver/framework.

Khi autoscale, số instance tăng có thể tăng tổng pool dù request chưa tăng tương ứng. Đặt ngân sách connection toàn hệ thống và giữ khoảng dành cho vận hành theo phiên bản/chính sách PostgreSQL.

Giới hạn PostgreSQL

Tài liệu PostgreSQL mô tả max_connections cùng cơ chế kết nối dự phòng. Không tăng giá trị chỉ để hết lỗi mà chưa tính tài nguyên. Memory của truy vấn, connection và tác vụ nền cần được xem cùng tải thực tế.

Kiểm tra connection bị giữ lâu, transaction chưa kết thúc và lỗi ứng dụng không trả connection về pool. Truy vấn nhanh nhưng mở transaction rất lâu vẫn có thể gây vấn đề cho hệ thống.

PgBouncer và chế độ pooling

PgBouncer có các chế độ session, transaction và statement với đặc tính khác nhau. Transaction pooling trả kết nối server về pool sau transaction nhưng không tương thích tự động với mọi cách dùng trạng thái session. Kiểm tra tính năng ứng dụng, driver và phiên bản pooler trước khi đổi.

Không mặc định prepared statement, temporary state hoặc session setting đều hoạt động giống kết nối trực tiếp. Dùng ma trận tính năng và thử các luồng ứng dụng quan trọng trên đúng bộ phiên bản.

Quy trình chọn pool size

1. Đếm instance, process, worker và pool từng thành phần.
2. Đo active query, connection idle, wait và transaction kéo dài.
3. Đặt giới hạn toàn hệ cùng phần dự phòng quản trị.
4. Thử tải với nhiều giá trị pool, quan sát latency và lỗi.
5. Kiểm tra khi tăng instance hoặc database restart.
6. Ghi timeout, retry và runbook xử lý nghẽn.

Pool quá lớn có thể tăng tranh tài nguyên; quá nhỏ có thể tạo queue. Chọn theo throughput và latency đạt yêu cầu, không theo số user đăng ký. Retry cần giới hạn để tránh khuếch đại lỗi.

Multi-tenant và quyền truy cập

Pool limit có thể hỗ trợ quản lý tài nguyên nhưng không thay authorization. Quyền dữ liệu phải được kiểm tra ở backend và database theo thiết kế. Nếu dùng tenant qua session state, phải xác nhận state không rò giữa request khi pooling; thử truy cập chéo tenant.

Khi thuê máy chủ, gửi tổng process/instance, workload database và số liệu chờ pool. Storage hoặc query tối ưu có thể mang lại lợi ích hơn việc tăng connection limit.