NUMA Node Spanning Performance Impact — Remote Memory Access After DRS Migration

Quick Answer

The VM spanning multiple NUMA nodes and causing remote memory access is the correct diagnosis because the esxtop data points precisely at memory locality rather than at CPU contention. Low CPU ready time rules out scheduling contention as the cause, since the vCPUs are not waiting for physical cores to become available; instead, the high remote memory figure shows that when a vCPU executes, the memory it needs is frequently sitting on a different NUMA node than the one it is running on, which is slower to access than local memory. With 16 vCPUs assigned and each socket offering 12 cores, this VM's vCPU count exceeds what a single NUMA node can provide, so unless it lands cleanly and stays within its NUMA boundary, it will span nodes and incur that remote-access penalty, and a DRS migration to a different host, even one with identical specs, can easily change exactly how the VM is placed relative to those NUMA boundaries. This is distinct from issues like memory shares, which only affect prioritization during contention rather than physical placement, or Transparent Huge Pages, which the metrics here do not implicate. Whenever a performance drop follows a vMotion or DRS migration and esxtop shows low ready time but elevated remote memory access alongside a high CPU cost figure, treat NUMA placement, not scheduling or contention, as the primary suspect.