NUMA and hugepages on big machines
On a server with many cores and a lot of memory, two invisible things quietly decide your performance: which memory a core has to reach across the board for, and how hard the CPU works to keep track of it all.
A small server has one pool of memory and every core reaches it equally. A big one — two sockets, hundreds of gigabytes — does not. Memory is attached to each socket, and a core reaching memory on the other socket pays a real latency penalty. That is NUMA, and ignoring it leaves performance on the table.
What NUMA is, briefly
Non-Uniform Memory Access means the cost of reaching memory depends on where the memory and the core are. Local memory is fast; remote memory (on the other socket) is slower. The kernel tries to keep a process’s memory local to the core running it, but under load it cannot always win.
numactl --hardware
That shows the nodes and the distances between them. Two nodes with a distance much higher than 10 to each other is the penalty you are trying to avoid paying.
Pinning keeps work local
For a workload that fills a socket — a big database, a busy VM — pinning it to one NUMA node keeps its memory local and its performance predictable. A database that drifts across both sockets spends cycles reaching remote memory for no reason. See database basics and running virtual machines.
Hugepages: fewer, bigger pages
The CPU tracks memory in pages, normally 4 KB each. On a machine with hundreds of gigabytes that is a staggering number of pages to keep addresses for, and the lookup table (the TLB) starts missing. Hugepages — 2 MB or 1 GB each — mean far fewer pages to track, fewer misses, and measurably faster access for memory-heavy workloads.
Who actually benefits
- Large databases — PostgreSQL and MySQL both use hugepages well; see running PostgreSQL
- Big VMs — backing guest memory with hugepages cuts overhead
- In-memory stores holding tens of gigabytes — see Redis
Measure before you tune
None of this helps a small or idle server — it is for machines genuinely large enough to feel the geometry. Confirm there is a problem first (remote-memory traffic, TLB misses) rather than pinning and reserving hugepages on faith. On a modest box it is effort for nothing; on the right box it is free speed.
We size it with you
If you are ordering a large multi-socket machine for a specific workload, tell us what it runs — the right memory layout is part of the spec, not an afterthought. See how much server do you actually need.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base