How does memory latency vary across NUMA nodes?
In a multi-socket server, like the Bare Metal instances in OCI, not all memory is "created equal." NUMA (Non-Uniform Memory Access) is the architectural reality where the speed of a memory request depends entirely on the physical distance between the CPU core and the RAM stick.
For your blog, here is how memory latency changes when your data "travels" across NUMA nodes.
In a NUMA system, each CPU socket has its own integrated memory controller and its own dedicated bank of RAM. This is its Local Node.
Local Access: When Core 0 on Socket 0 asks for data in Socket 0's RAM, the request travels a very short physical distance. Latency is typically 70–90 nanoseconds.
Remote Access: When Core 0 on Socket 0 needs data stored in Socket 1's RAM, the request must exit the CPU, cross the Interconnect (Intel UPI or AMD Infinity Fabric), and ask the other CPU's controller for the data.
The Penalty: This "remote" trip typically adds 50% to 100% more latency. In a 2-socket OCI instance, remote latency can jump to 150–200 nanoseconds.
The "bridge" between sockets (the Interconnect) is the primary cause of latency variation. In 2026, these bridges are faster than ever, but they still have limitations:
Hop Counts: In massive 4-socket or 8-socket systems, data might have to take "two hops" to reach a distant node, increasing latency with every jump.
Contention: If multiple cores are all trying to fetch remote data simultaneously, the Interconnect becomes congested. This causes "Tail Latency" spikes, where a memory request that usually takes 150ns suddenly takes 500ns because it was stuck in a hardware queue.
Modern CPUs allow you to further "dice" the hardware to reduce latency variation even within a single socket.
Intel SNC (Sub-NUMA Clustering): Splits a single physical CPU into two or four virtual NUMA nodes. This keeps data closer to the specific clusters of cores, reducing the "internal" travel time within the silicon.
AMD NPS (Nodes Per Socket): Allows you to configure a socket as NPS1 (one big node), NPS2, or NPS4.
NPS4 provides the lowest possible latency but requires your application to be "NUMA-aware" so it doesn't accidentally ask for data from a different quadrant of the same chip.
| Workload | Sensitivity | Result of Poor NUMA Alignment |
| In-Memory DBs (Redis, SAP) | Extreme | 30% drop in throughput if threads migrate away from their data. |
| High-Frequency Trading | Critical | Even a 20ns "Remote" penalty is considered a system failure. |
| AI Inference | High | 15–20% increase in token-generation latency if weights are remote. |
| Web Servers | Low | Usually I/O bound; 50ns of memory latency is negligible. |
If you want to include a "How-To" snippet for your readers, they can check their NUMA latency "distance" using the numactl tool:
# Check the distance matrix between nodes
numactl --hardware
A distance of 10 usually represents local access, while 20 or 21 represents a remote socket hop.
"NUMA latency is the 'hidden tax' of scaling. As you move from 1 socket to 2 or 4, your total memory capacity grows, but your average speed can drop. The goal of a high-performance OCI architect is to ensure that a thread and its data are 'married' to the same NUMA node, keeping every access in the 90ns fast lane."