TopDev AI Robot TopDev
#Backend & Microservices#Cơ sở dữ liệu & Tối ưu#DevOps & Cloud

Database Connection Pooling: Vì sao server 16GB RAM bị nghẽn kết nối khi traffic tăng đột biến?

Thu Trang (Backend Engineer)
📖 2 phút đọc 💬 1 phản hồi
⚡ Tóm tắt 30 giây bởi TopDev AI
AI Overview

Nghịch lý: Càng mở nhiều kết nối Database, hệ thống càng chậm Khi website bị nghẽn, phản xạ đầu tiên của nhiều kỹ sư là tăng thông số maxconnections trong PostgreSQL từ 100 lên 1.000 hoặc 2.000. Kết …

☰ Mục lục bài viết (5 phần) Mở / Đóng mục lục

Nghịch lý: Càng mở nhiều kết nối Database, hệ thống càng chậm#

Khi website bị nghẽn, phản xạ đầu tiên của nhiều kỹ sư là tăng thông số max_connections trong PostgreSQL từ 100 lên 1.000 hoặc 2.000. Kết quả là chỉ vài phút sau, toàn bộ server PostgreSQL bị treo cứng, CPU chạm 100% dù số lượng query xử lý thành công không hề tăng.

Vì sao lại có hiện tượng kỳ lạ này?

Bản chất của một kết nối trong PostgreSQL#

Trong kiến trúc của PostgreSQL:

  • Mỗi một kết nối từ client tương ứng với một tiến trình độc lập của hệ điều hành (Process), không phải là một luồng (thread) nhẹ.
  • Mỗi tiến trình ngốn từ 5MB đến 20MB RAM để khởi tạo bộ nhớ đệm (work_mem, context state).
  • Khi có 1.000 kết nối hoạt động đồng thời trên CPU chỉ có 8 hoặc 16 cores, CPU sẽ dành phần lớn thời gian quý giá chỉ để chuyển đổi ngữ cảnh (Context Switching) giữa 1.000 tiến trình thay vì thực thi query tính toán!

Giải pháp: Quy tắc kích thước Pool chuẩn và Sử dụng PgBouncer#

Công thức vàng của nhóm phát triển PostgreSQL:

CODE
Pool Size = (Core Count * 2) + Effective Spindle Count

Ví dụ: Server của bạn có 8 CPU Cores và ổ cứng NVMe SSD, kích thước Connection Pool tối ưu nhất chỉ nên dao động từ 16 đến 32 kết nối!

CODE
Client Requests (Hàng ngàn requests)
       │
       ▼
[ PgBouncer (Transaction Pooling) ]
       │  (Giữ kết nối siêu nhẹ, chỉ cấp connection khi chạy query)
       ▼
PostgreSQL Server (Chỉ mở đúng 30-50 kết nối thực sự)

Hiệu quả đo lường thực tế#

Sau khi đưa PgBouncer vào chế độ pool_mode = transaction:

  • Phục vụ ổn định 8.000 requests/giây mà số lượng kết nối thực tế trên Postgres chỉ duy trì ở mức 40.
  • Giảm 60% tình trạng tranh chấp CPU do Context Switching.
  • Không còn bất kỳ lỗi nào dạng FATAL: sorry, too many clients already.

Góc thảo luận#

Anh em quản lý pool kết nối trực tiếp trong mã nguồn backend (HikariCP, pg-pool) hay qua PgBouncer/RDS Proxy chuyên dụng?


Xem thêm nội dung liên quan:

Chia sẻ thảo luận này:

Thảo luận

1 phản hồi

Ý kiến từ cộng đồng kỹ sư TopDev
💬

Tham gia thảo luận

Cộng đồng mở · Đăng nhập 1-chạm qua Google
  1. Hoàng Nam (Tech Lead)
    #1

    Chuẩn luôn! Bài viết kinh điển "About Pool Sizing" của HikariCP cũng chỉ ra rằng 1 server 8 core chỉ cần pool tầm 20 connection là đạt throughput tối đa. Mở 1000 connection chỉ làm chết database nhanh hơn thôi.

Bài liên quan trong #Backend & Microservices

1
TopDev AI Companion
AI
✓ Đã sao chép link