A capacity dashboard answers how much RAM a server has. It does not, by itself, explain how efficiently a particular application reaches that memory. On a NUMA system, location is part of the performance picture.
That distinction matters when evaluating an upgrade. Additional memory may be necessary, but the purchasing decision becomes stronger when the team can explain whether it is addressing insufficient capacity, an uneven configuration or a workload-placement issue.
Local and remote memory have different access paths
NUMA means non-uniform memory access. Red Hat’s architecture guide explains that processors can access memory local to their node and memory on other nodes, with remote access carrying additional latency. A socket is not always a single NUMA node; some designs expose more than one. Red Hat’s memory-system performance brief provides the architectural background.
Follow the application’s memory access
Thread on node A → memory on node A
Thread on node A → interconnect → memory on node B
The practical implication is to examine the workload and topology together. A machine-wide free-memory total cannot establish that a particular process has enough memory close to the CPUs doing its work.
Build a baseline that answers a business question
Start with the symptom: slower transaction response, a longer batch window or reduced consolidation headroom. Record the application metric that will determine whether a change helped. Keep workload volume and concurrency with the measurement so unlike runs are not mistaken for a performance trend.
Then capture topology and memory distribution. Red Hat documents tools such as lscpu for CPU topology and numastat for per-node memory information. These are useful observations, but allocation statistics alone are not a measurement of application latency or a complete trace of remote accesses.
Ask the platform administrator to record the operating-system or hypervisor version, firmware settings, installed memory layout and any placement policy already in effect. For virtual machines, include the relevant host and guest configuration. This creates a reproducible starting point instead of a collection of isolated screenshots.
Test one explanation at a time
A useful trial has a hypothesis, an agreed change and a rollback. For example, the team might test whether a vendor-supported placement adjustment improves a specific batch job while keeping the hardware and input data constant.
Do not make manual pinning the default response to the word NUMA. Ask how a proposed policy interacts with the workload’s memory demand, competing applications and the scheduler already in use. Validate the approach against documentation for the deployed software version. The Red Hat brief linked above is historical architectural context, not a current configuration recipe.
Compare the same application metrics before and after the trial, including busy periods. Retain a change only when the result supports the operational objective. A tidier placement diagram is not sufficient if the application gains nothing or another service loses capacity.
Translate the findings into a memory requirement
If additional RAM is warranted, specify the complete supported layout rather than just a larger total. Ask for a slot-by-slot proposal, the resulting capacity distribution and an explanation of how the configuration supports the intended workload.
Include expansion plans in that discussion. A purchase that meets today’s aggregate target may be less attractive if the next change requires replacing most of the modules. Compare the usable configuration and upgrade path alongside the price per module.
The best upgrade proposal connects a measured workload need to an approved memory layout.
Prepared November 10, 2026. NUMA concepts and tool descriptions draw on Red Hat’s November 2014 performance brief. The diagram and evaluation workflow are Ocitech’s explanatory material. No numerical speedup, current software default or universal tuning policy is claimed.