Skip to main content

SecuraWall.com

Email security and continuity

Explore
Technical Guide · Server & Virtualization

What Is NUMA? Virtualization Performance Basics

NUMA describes systems where CPUs and memory are organized into nodes and memory-access cost differs between local and remote access.

LAST TECHNICAL REVIEW:
Server & Virtualization

Why This Topic Matters

NUMA describes systems where CPUs and memory are organized into nodes and memory-access cost differs between local and remote access.

Key Decision Points

Consider NUMA boundaries when sizing large VMs.

Know the physical NUMA topology of the host.

Do not size very large VMs using aggregate resources alone.

Check remote-memory effects during performance analysis.

Architecture and operating model

NUMA effects depend on memory locality, sockets and VM placement. A VM exceeding physical-node capacity may require remote memory or different vNUMA exposure; exact behavior is hypervisor-specific. CPU affinity or pinning is not an automatic improvement for every workload.

  1. 1Physical NUMA topology
  2. 2VM CPU/RAM placement
  3. 3Local and remote access
  4. 4Application measurements
Validate topology changes using application latency, not CPU percentage alone.

Design parameters

Locality
Compare vCPU and memory placement with physical NUMA boundaries; remote memory can add latency.
vNUMA and size
Review VM size, guest support and memory assignment together; extra vCPUs do not guarantee speed.
Peak workload
Collect CPU, memory, storage and network measurements for the same period. A single utilization percentage does not determine sizing.
N-1 capacity
Calculate capacity after losing one component. Normal spare headroom does not prove sufficient failure-state capacity.
Compatibility chain
Review CPU, firmware, drivers, hypervisor and guest-application support together.
Operating reserve
Backup, migration, maintenance and growth compete for resources. Do not reserve headroom using averages alone.

Worked example

Assume 128 GB per NUMA node. Examine placement, guest topology and workload latency for a 192 GB VM. Compare a 96 GB test VM using the same dataset while distinguishing reduced-cache effects from locality effects.

Example commands: replace lab values and confirm permissions and software versions before use.

lscpu
numactl --hardware

Troubleshooting

ObservationLikely cause / distinctionVerification
RAM is available but latency is highRemote memory or scheduling placement may be involved.Compare NUMA placement and p95 latency under equivalent controlled load.
Application is slow despite low CPU usageStorage, locking, hot cores or scheduling waits may be hidden by aggregate CPU usage.Correlate application latency with core, storage and hypervisor waits.
Host overloads after failureCapacity planning may cover normal placement but omit N-1 conditions.Measure remaining RAM, CPU and storage latency during a controlled failure.
Performance worsened after a changeDrivers, firmware, NUMA placement or resource allocation may have changed.Compare before and after under equivalent load, changing one variable at a time.

Acceptance checks

  1. Validate topology changes using application latency, not CPU percentage alone.
  2. Test representative peak load together with maintenance tasks.
  3. Verify service and writes after losing a host or connection.
  4. Check guest OS and application support against official matrices.
  5. Validate device, service and storage health after reboot.
  6. Record raw and usable capacity separately.

Related concepts

NUMA locality

On NUMA systems a processor may access nearby and remote-node memory at different costs. VM vCPU and memory sizes must be assessed against physical node capacity and hypervisor placement. More vCPUs do not always improve performance: reduced locality and scheduling waits can make it worse. Record physical topology, topology exposed to the guest and the workload’s memory behavior together. Compare changes under the same load, using application latency and remote-memory effects rather than CPU percentage alone.

Resource contention

Contention occurs when workloads sharing CPU, memory, storage or a link make each other wait. Apparent spare total capacity can hide a hot core or single-queue bottleneck. Correlate backup jobs, antivirus scans, index maintenance and user traffic on a common timeline. Confirm the bottleneck before adding resources. Run a workload alone and with its usual competitors to separate shared-resource effects, and report peak-hour latency alongside average utilization.

Capacity and usable headroom

Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.

IOPS and block size

IOPS measures operations per second, whereas MB/s measures transferred data. Identical IOPS values produce very different bandwidth at different block sizes. For example, 10,000 operations/s at 4 KiB is approximately 39.1 MiB/s. Read/write mix, random versus sequential access and protection mechanisms affect the result. Measure actual block distributions and concurrency rather than transferring a benchmark result directly to production. High disk IOPS does not prove good application response; latency must be examined alongside it.

Availability versus recovery

High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.

Failover and failback

Failover moves service to another component; failback returns it to the preferred location. Their risks and sequencing may differ. DNS updates, routing, sessions, replication lag and application dependencies determine user interruption. Define failover triggers, false-alarm behavior and approval for returning service. Simply shutting down a VM does not test every failure type. Measure network, storage and management-plane failures separately.

Primary documentation

Who · How · Why

How This Content Was Prepared

WHO?

Doz Teknoloji Technical Team

This content is based on the technical evaluation approach used across Doz Teknoloji's enterprise IT practice areas.

HOW?

Technical criteria + primary sources

The topic was cross-checked against vendor documentation, publications from standards bodies and other relevant official technical sources.

WHY?

Improve decision quality

This guide explains the technical term and the criteria to consider when making purchasing, architecture or operational decisions.

LAST TECHNICAL REVIEW

Related Enterprise Solutions

Explore the related service and solution pages to plan implementation.

Let's Evaluate Your Technical Requirement

Share your current infrastructure, user count or technical objective and we can help clarify product, licensing or project scope.

Send a Technical Request
Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!