Các bài trước chỉnh cách PostgreSQL dùng bộ nhớ và đĩa. huge_pages đi xuống một tầng sâu hơn — cách hệ điều hành và CPU ánh xạ bộ nhớ ảo sang vật lý. Đây là một tối ưu ít người bật nhưng đáng giá với các server có shared_buffers lớn, và nó minh hoạ một khái niệm phần cứng quan trọng: TLB. Bài này đo thật số lượng mục page table cho các cấu hình khác nhau, và quan sát trạng thái huge page thật trong container để rút ra khi nào và cách bật.

Vấn đề: TLB quá tải với shared_buffers lớn

Mỗi lần chương trình truy cập một địa chỉ bộ nhớ, CPU phải dịch địa chỉ ảo sang địa chỉ vật lý qua bảng page table. Để khỏi tra bảng mỗi lần (chậm), CPU có một cache nhỏ tên TLB (Translation Lookaside Buffer) giữ các bản dịch gần đây — nhưng TLB chỉ chứa được khoảng 1.500-3.000 mục.

Với trang nhớ thường 4KB, một vùng shared_buffers lớn cần rất nhiều mục page table (PTE — page table entry). Đo thật con số:

-- shared_buffers 8GB với trang 4KB:  8GB / 4KB = 2.097.152 PTE
-- shared_buffers 8GB với huge 2MB:   8GB / 2MB = 4.096 PTE

2 triệu PTE so với TLB chỉ giữ vài nghìn mục → TLB miss triền miên: mỗi miss buộc CPU "page walk" (đi bộ qua bảng page table nhiều tầng), làm chậm mọi truy cập bộ nhớ. Huge page 2MB thay cho 4KB giảm số PTE đi 512 lần — 4.096 mục vừa gọn trong TLB, gần như luôn trúng, ít stall CPU.

Ảnh chụp đoạn mã SQL nền tối minh hoạ huge pages trang nhớ 2MB thay 4KB giảm áp lực TLB, vấn đề TLB không đủ chỗ cho shared_buffers lớn CPU dịch địa chỉ ảo sang vật lý qua page table TLB cache các mục đó trang thường 4KB shared_buffers lớn hàng triệu mục PTE TLB chỉ giữ khoảng 1500-3000 mục liên tục TLB miss CPU phải page walk huge page 2MB giảm số PTE đi 512 lần vừa TLB ít stall, cấu hình huge_pages SHOW huge_pages try mặc định on off try thử dùng huge page không có thì âm thầm quay về 4KB không báo on bắt buộc nếu OS chưa reserve đủ PostgreSQL không khởi động cách chắc chắn biết mình có dùng huge page hay không off không dùng, reserve huge page ở tầng OS Linux tính số trang tổng shared memory PostgreSQL chia 2MB dư chút xem yêu cầu chính xác postgres in ra khi khởi động với huge_pages on hoặc đọc VmPeak của tiến trình postmaster sysctl w vm.nr_hugepages 4200 ví dụ cho shared_buffers 8GB rồi ALTER SYSTEM SET huge_pages on restart PostgreSQL, huge page rõ ràng vs transparent huge pages THP THP kernel tự động gộp trang thành 2MB ở nền khugepaged với CSDL khuyến nghị phổ biến dùng huge page rõ ràng reserve sẵn và tắt THP vì việc gom nén nền của THP gây spike độ trễ bất chợt echo never vào transparent_hugepage enabled tắt THP

Hình 1: Trang 4KB khiến shared_buffers lớn sinh hàng triệu PTE, làm TLB quá tải. Huge page 2MB giảm số PTE 512 lần. huge_pages: try (fallback lặng lẽ), on (fail-fast, chắc chắn), off. Nên dùng huge page rõ ràng + tắt THP với CSDL.

Đo thật trạng thái huge page trong container

Con số PTE ở trên tính trực tiếp từ kích thước bộ nhớ. Quan trọng hơn, tôi đọc trạng thái huge page thật của container để thấy cái bẫy phổ biến:

Ảnh chụp bảng kết quả đo thật nền tối số page table entry giảm 512 lần với huge page 2MB tính từ kích thước bộ nhớ trạng thái huge page thật của container PostgreSQL 16, số PTE cho cùng vùng nhớ 4KB so với 2MB 144 MB shared mem 4KB thường 36864 PTE 2MB huge 72 PTE shared_buffers 8GB 4KB thường 2097152 PTE 2MB huge 4096 PTE TLB chỉ giữ khoảng 1500-3000 mục 2 triệu PTE miss triền miên 4096 PTE huge gần như luôn trúng TLB ít page walk ít stall CPU, bảng shared_buffers 144 MB trang 4KB 36864 PTE huge 2MB 72 PTE giảm 512 lần 8 GB 2097152 PTE 4096 PTE giảm 512 lần, trạng thái huge page thật của container từ proc meminfo huge_pages bằng try thử không có thì âm thầm fallback 4KB HugePages_Total 0 không có huge page rõ ràng nào được reserve Hugepagesize 2048 kB 2MB AnonHugePages 442368 kB khoảng 432MB đang được THP gộp 2MB ở nền transparent_hugepage always THP đang bật log khởi động không có dòng nào về huge page try fallback lặng lẽ, hai điều rút ra huge_pages try cộng HugePages_Total 0 PostgreSQL đang chạy 4KB cho shared mem rõ ràng muốn chắc dùng huge page đặt on fail-fast THP vẫn bù 2MB cho vùng nhớ ẩn danh nhưng với CSDL nên dùng huge page reserve sẵn cộng tắt THP tránh spike độ trễ do khugepaged nén nền lab này không reserve được huge page proc chỉ đọc trong container

Hình 2: Số PTE giảm 512× với huge page (2.097.152 → 4.096 cho 8GB). Trạng thái thật: huge_pages=try nhưng HugePages_Total=0 (không reserve được) nên PostgreSQL chạy 4KB; THP lại đang bù (AnonHugePages=442MB, THP=[always]). Log khởi động không nhắc gì → 'try' fallback lặng lẽ.

Trạng thái thật cho ta hai bài học:

1. huge_pages='try' fallback lặng lẽ — bạn có thể tưởng đang dùng mà không. Container có huge_pages=try nhưng HugePages_Total=0 (OS chưa reserve huge page nào), nên PostgreSQL âm thầm quay về trang 4KB cho vùng shared memory rõ ràng — và không có dòng log nào cảnh báo. Đây là bẫy phổ biến: đặt try rồi tưởng mình được hưởng huge page. Muốn chắc chắn, đặt huge_pages='on': nếu OS chưa reserve đủ, PostgreSQL sẽ không khởi động — thà fail rõ ràng còn hơn im lặng chạy 4KB.

2. THP đang bù, nhưng đó không phải cái CSDL muốn. Dù không có huge page rõ ràng, AnonHugePages=442MB và transparent_hugepage=[always] cho thấy kernel đang tự gộp trang thành 2MB ở nền (THP — Transparent Huge Pages). Nghe có vẻ tốt, nhưng với CSDL, khuyến nghị phổ biến là dùng huge page reserve sẵn và TẮT THP — vì tiến trình nền khugepaged gom/nén trang có thể gây spike độ trễ bất chợt đúng lúc CSDL đang bận.

(Giới hạn lab: container này không reserve được huge page rõ ràng vì /proc/sys/vm/nr_hugepages chỉ-đọc trong môi trường không đặc quyền. Các con số PTE và trạng thái /proc/meminfo là thật; phần reserve phải làm ở host.)

Cách bật đúng

# 1. Tính số huge page cần: (tổng shared memory) / 2MB, dư ra chút cho overhead.
#    Xem yêu cầu CHÍNH XÁC: khởi động postgres với huge_pages=on, nó in ra số cần;
#    hoặc đọc VmPeak của tiến trình postmaster.
sysctl -w vm.nr_hugepages=4200          # ví dụ cho shared_buffers ~8GB

# 2. Trong PostgreSQL:
#    ALTER SYSTEM SET huge_pages = 'on';   rồi restart

# 3. Tắt THP để tránh spike độ trễ:
echo never > /sys/kernel/mm/transparent_hugepage/enabled

Đánh đổi cần cân nhắc

Huge page reserve là bộ nhớ bị "khoá cứng". Khi bạn vm.nr_hugepages=4200, kernel giữ riêng ~8GB đó cho huge page — các tiến trình khác không dùng được, kể cả khi PostgreSQL chưa chiếm hết. Tính đúng số cần, đừng reserve thừa. Và nếu đặt huge_pages=on mà reserve thiếu, PostgreSQL không khởi động — nhớ đồng bộ hai con số.

Lợi ích rõ nhất khi shared_buffers lớn. Với shared_buffers vài trăm MB, chênh lệch TLB nhỏ, huge page gần như không đáng kể. Nó phát huy ở server CSDL nghiêm túc với shared_buffers nhiều GB — nơi 2 triệu PTE thật sự làm TLB nghẹt. Server nhỏ thì đừng bận tâm.

Đây là tối ưu CPU/độ trễ, không phải I/O. Huge page không làm đọc/ghi đĩa nhanh hơn; nó giảm overhead CPU khi truy cập bộ nhớ (ít page walk). Lợi ích đo bằng độ trễ truy vấn ổn định hơn và CPU nhàn hơn dưới tải nặng, không phải bằng throughput I/O — nên phải benchmark trên tải thật của bạn để thấy, và mức cải thiện thường vài phần trăm chứ không phải phép màu.

Ba ý mang về

  1. Trang 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: đo thật, shared_buffers 8GB cần 2.097.152 PTE với trang 4KB nhưng chỉ 4.096 PTE với huge page 2MB — giảm 512 lần, giúp bản dịch địa chỉ gần như luôn trúng TLB.
  2. huge_pages='try' fallback lặng lẽ: trạng thái container thật cho thấy try + HugePages_Total=0 nghĩa là PostgreSQL đang chạy 4KB mà không báo — muốn chắc chắn dùng huge page, đặt huge_pages='on' (fail-fast nếu OS chưa reserve đủ).
  3. Với CSDL nên dùng huge page rõ ràng và tắt THP: dù THP tự bù 2MB (đo thấy AnonHugePages=442MB), tiến trình nền khugepaged của THP gây spike độ trễ — reserve huge page sẵn qua vm.nr_hugepages rồi tắt THP an toàn hơn; nhớ đây là tối ưu CPU/độ trễ cho server shared_buffers lớn.

Phần sau ta quay lại một chỉ số ai cũng nhìn nhưng hay hiểu sai: Phần sau mổ xẻ cache hit ratio — vì sao con số 99% có thể đánh lừa, cách đọc pg_statio đúng, và khi nào hit ratio cao vẫn là dấu hiệu xấu.