full_page_writes tạo ra full-page image trong WAL (chống torn page); wal_compression nén chúng lại. Đo thật: bật wal_compression giảm WAL 17-30% tuỳ độ nén của dữ liệu, FPI vẫn còn nên vẫn an toàn. Tắt full_page_writes giảm 35% nhưng bỏ hẳn chống torn page — gần như không bao giờ nên làm. PostgreSQL 16.
Trang nhớ thường 4KB khiến shared_buffers lớn sinh hàng triệu mục page table, làm TLB của CPU quá tải. Huge pages 2MB giảm số mục đi 512 lần. Đo thật trạng thái container: huge_pages=try âm thầm fallback, THP đang bù 2MB. Vì sao nên dùng huge page rõ ràng và tắt THP. PostgreSQL 16.
Cache hit ratio 99% được coi là chỉ số sức khỏe, nhưng nó đánh lừa theo ba cách. Đo thật: một truy vấn self-join có hit ratio 100% (không chạm đĩa) vẫn mất 1,4 giây vì nhân 25 triệu dòng. Ratio đo dữ liệu đến từ đâu, không đo truy vấn tốt hay xấu — công cụ đúng là EXPLAIN BUFFERS. PostgreSQL 16.
PostgreSQL fork một tiến trình riêng cho mỗi kết nối, nên nhiều kết nối tốn RAM và CPU. Đo thật: 60 kết nối tạo 60 tiến trình, ps RSS gợi ý 16 MB/kết nối nhưng đó là con số ảo do đếm trùng shared_buffers — RAM thật của kết nối idle chỉ ~0,44 MB. Vì sao vấn đề thật nằm ở kết nối hoạt động và context switch. PostgreSQL 16.
Một kết nối PostgreSQL có hai loại chi phí: thiết lập (fork backend, xác thực, nạp catalog) và bộ nhớ tích lũy. Đo thật: mở lại kết nối mỗi truy vấn cho 1.306 TPS so với 24.228 TPS khi tái dùng — chậm 18 lần. Và bộ nhớ backend phình từ 1,3 MB lên 2,1 MB khi chạm nhiều bảng. Vì sao pooling là giải pháp kỹ thuật. PostgreSQL 16.
Đặt max_connections cao không cho throughput cao hơn — số truy vấn chạy song song bị chặn bởi số core CPU. Đo thật trên máy 10 core: TPS đạt đỉnh ở ~16 client rồi TỤT 20% khi lên 90 client vì context switch. Vì sao max_connections là trần an toàn chứ không phải mục tiêu, và công thức thực tế. PostgreSQL 16.