Why Huge Pages matter for Postgres
4 hours ago
- #Memory Optimization
- #Huge Pages
- #PostgreSQL
- Huge pages are large memory units (2MB or 1GB) that allow one page-table entry to cover much more memory compared to standard 4KB pages, reducing the number of translations the CPU's TLB must cache.
- Postgres is sensitive to page size because its shared_buffers cache is mapped by each backend's page tables; with 4KB pages, large caches can consume excessive RAM for page tables and cause TLB misses, slowing reads.
- Using huge pages (e.g., 2MB) dramatically reduces page-table memory usage per connection—from ~31MB to ~0.5MB per connection in tests—and improves TLB coverage, keeping the hot working set in cache and boosting throughput.
- ClickHouse Managed Postgres ensures huge pages by reserving memory early (25% of RAM), configuring huge_pages = 'on' to prevent silent fallback, and sizing shared_buffers to fit the reserved pool via measurement rather than assumption.
- Tests on an EC2 instance showed that with 200 connections, 4KB pages led to 6.12GB of page tables versus only 111MB with 2MB huge pages, and throughput increased by 12% with huge pages due to reduced translation overhead.