Cloud & AWSSố connection tối đa của RDS phụ thuộc class instance (mặc định của tham số max_connections tính theo bộ nhớ), nên nó không tự tăng khi bạn thêm container. Tổng connection ứng dụng mở ra là số instance × pool size mỗi instance — nhân lên rất nhanh. Với Lambda còn tệ hơn: mỗi execution environment giữ pool riêng, concurrency 200 thì có thể thành 200 pool.
Một connection Postgres/MySQL không rẻ: mỗi cái tốn bộ nhớ ở phía server, nên nâng max_connections bằng parameter group là đổi lỗi kết nối thành hết RAM và swap, không phải cách sửa.
Xử lý theo thứ tự:
1. Tính lại pool size. Pool không cần bằng số request đồng thời — nó bị chặn bởi số core và IO của DB. Pool nhỏ mà xếp hàng thường cho throughput cao hơn pool to gây tranh chấp. Đặt max theo ngân sách tổng: max_connections × 0.8 / số instance dự kiến ở đỉnh.
2. Đặt connectionTimeout ngắn để request chờ pool bị fail nhanh thay vì dồn ứ, kèm retry có backoff và jitter.
3. Thêm connection proxy. RDS Proxy đứng giữa, ghép nhiều connection ứng dụng vào một nhóm connection tới DB (multiplexing), giữ connection qua các lần failover và giảm thời gian gián đoạn. Đây là lời giải chuẩn cho Lambda và cho fleet container co giãn mạnh. Tự vận hành thì PgBouncer chế độ transaction pooling cho kết quả tương tự.
4. Xem lại truy vấn giữ connection lâu: transaction mở suốt lời gọi API bên ngoài, hoặc idle in transaction — hai thứ này chiếm slot mà không làm việc gì.
Lưu ý khi dùng pooling ở chế độ transaction: không dùng được session state như prepared statement kiểu session, temporary table hay advisory lock giữ qua nhiều câu lệnh.