June 29, 2026

Server drama: too far, too furious

NUMA: Cores, memory, and the distance between them

Identical machines, totally different speed — and commenters are losing it

TLDR: Edera says it fixed a hidden server problem where two identical virtual machines can perform very differently just because memory is physically farther from the processor. Commenters piled on with horror stories, calling it an invisible speed killer, while others demanded to know why modern systems still haven’t solved this automatically.

Two supposedly identical virtual machines walk into a server... and one comes out 20% slower for no obvious reason. That’s the maddening setup behind Edera’s deep dive into NUMA, the very unglamorous but very real problem where a program can slow down simply because its memory lives “farther away” inside the machine. Edera says it has now made Xen virtualization aware of that hidden layout from end to end — basically teaching the system to stop acting surprised when distance inside a server actually matters.

But the real fireworks were in the comments, where engineers showed up like survivors of a niche horror movie. One person described a Go-based AI gateway that kept chewing CPU and throwing latency tantrums until they manually limited how many processor cores it could use. Another warned that it’s not just memory: even network cards can become part of the drama if the work is happening on the “wrong side” of the machine. The mood was a mix of war stories, frustration, and “how is this STILL a thing?”

And yes, there was a full-on generational feud. Some commenters called NUMA the “invisible performance killer” that keeps ambushing teams who don’t know to look for it. Others were openly baffled that in 2026, modern software still hasn’t made this automatic. Translation for non-server people: your app can be slow not because it’s broken, but because it’s sitting too far from its stuff — and the internet is split between “this monster is real” and “why haven’t we killed it already?”

Key Points

  • The article describes a case where two identical virtual machines on the same host differ in performance by 20% because one accesses memory across a NUMA interconnect.
  • Edera says it shipped changes to make Xen-based virtualization NUMA-aware across the guest, paravirtual I/O drivers, dom0, and the hypervisor.
  • NUMA systems differ from UMA systems because memory access latency and cost depend on the relationship between CPUs and physical memory banks.
  • The article explains that NUMA emerged as a response to scaling limits in UMA systems, including signal propagation, memory-controller bandwidth limits, package pin constraints, and bus contention.
  • It traces NUMA from 1990s enterprise systems to commodity x86 adoption with AMD Opteron in 2003 and Intel Nehalem with QPI in 2008, noting modern use of UPI and Infinity Fabric.

Hottest takes

"NUMA can cause really crappy performance" — lukax
"the amazing 'invisible' performance killler" — Twirrim
"I’m baffled by the fact that NUMA is still an issue in 2026" — jpecar
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.