Công Thức Định Cỡ Bộ Đệm PostgreSQL 17, PgBouncer & NVMe Trên PGSizer
Trong mô hình toán học xác định của PGSizer, chúng tôi tính toán mọi tham số dựa trên cơ chế quản lý trang 8KB của PostgreSQL 17, bộ đệm nhân Linux và bảng giá niêm yết công khai ngày 2026-11-12 — hoàn toàn không bịa đặt số liệu đo lab khi chưa có tệp log thực nghiệm.
1. Phương Trình Tập Dữ Liệu Nóng & shared_buffers Trên PGSizer
Chúng tôi xác định tổng RAM dựa trên tỷ lệ nhánh chỉ mục B-Tree/HNSW cần giữ thường trực trong bộ nhớ cộng với dung lượng tiến trình kết nối và vùng an toàn hệ điều hành:
RAM_Needed_GB = (Dataset_GB * Working_Set_Ratio) + Connection_Fork_RAM + OS_WAL_Guard
OLTP SaaS = 0.22 | Fintech Ledger = 0.28 | Analytical BI = 0.32 | PostGIS/pgvector = 0.42
shared_buffers = 25% RAM (30% Hybrid) | effective_cache_size = 75% RAM2. Giới Hạn An Toàn work_mem Khi Gộp Kết Nối Bằng PgBouncer Trên PGSizer
Mỗi phép sắp xếp hoặc Hash Join có thể cấp phát một vùng work_mem riêng. Nhờ PgBouncer gom kết nối ứng dụng ở chế độ transaction, PGSizer giới hạn chặt số tiến trình hoạt động đồng thời:
Safe_Sort_Pool_MB = Total_RAM_MB * 0.22
work_mem = clamp((Safe_Sort_Pool_MB / Active_Concurrent_Sort_Slots) * Workload_Factor, 4MB, 256MB)3. Dự Phòng 25% Không Gian Trống NVMe Cho MVCC, WAL & VACUUM Trên PGSizer
Ổ cứng SSD NVMe bị giảm tốc độ ghi nếu lấp đầy quá 80% và khiến pg_repack thiếu chỗ trống. Công thức PGSizer luôn cộng thêm 25% dung lượng dự phòng an toàn:
NVMe_Disk_GB = ceil(((Dataset_GB * Disk_Overhead_Factor) + WAL_Archive_GB) * 1.25)
random_page_cost = 1.1 | io_combine_limit = '128kB'