What is NUMA, and how do I inspect it on a dedicated server?
NUMA divides CPU and memory resources into locality domains. Access to local memory can have different latency or bandwidth characteristics from remote memory, so large databases, virtual machines and compute workloads may benefit from topology-aware placement. Pinning everything to one node without measuring can reduce available capacity and make performance worse.
Before you start
- Authorised access to the dedicated server and the named inspection tools.
Instructions
1. Inspect node membership and capacity
Use the installed numactl reporting option. A single node is a valid result; multiple sockets do not always map to exactly one NUMA node each.
numactl --hardwareReview node CPUs, memory size/free values and the distance table. These describe exposed topology, not an application-specific tuning recommendation.
2. Map processors to nodes
Confirm how the operating system sees logical CPUs and sockets before applying any affinity or memory-binding policy.
lscpu -e=CPU,NODE,SOCKET,CORECompare the application’s concurrency and memory footprint with node capacity. Preserve room for the operating system and other workloads.
Check the result
- The placement plan fits the actual topology and is tested with representative latency, throughput and memory-pressure measurements.
Troubleshooting
- A workload slows down after pinning
- It may exceed the chosen node’s memory, lose parallelism or create contention. Revisit the measured bottleneck rather than adding more binding rules.
- A guest sees different NUMA topology
- The hypervisor can expose a virtual topology. Inspect host and guest views separately.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.