Last updated:
An interesting performance topic in the current XenServer 9 known issues that is easy to overlook, particularly in larger Citrix environments.
When a XenServer host’s CPUs are fully utilized, so-called NUMA node drift may occur.
What does that mean?
Normally, XenServer tries to run a VM’s vCPUs on the NUMA node that also holds the associated memory.
Under heavy CPU saturation, this association may be lost:
vCPU → NUMA node 0
RAM → NUMA node 1
The CPU then has to access memory on the other NUMA node.
➡️ Higher latency
➡️ Worse performance
➡️ Citrix VDAs may become noticeably slower
The tricky part:
Inside the VDA, this may initially look fairly unremarkable.
You can quickly end up investigating Windows, Citrix policies, FSLogix, storage or the application even though the actual issue is at the hypervisor layer.
XenServer 9 provides a particularly useful performance counter for this:
NUMA non-affine vCPUs
If this value rises alongside high host CPU utilization, it is worth examining NUMA distribution.
The workaround documented by XenServer is also noteworthy:
👉 Leave at least one CPU free on the host.
This allows XenServer to restore NUMA affinity.
My learning for Citrix performance analysis:
Do not look only at the VDA’s CPU utilization.
Always check the NUMA layer on heavily utilized XenServer hosts.
Sometimes a VDA is slow not because it lacks CPU, but because its CPU is accessing the wrong memory. 😉
