NUMA-Optimierung in XenServer 9

Last published : Oct 07, 2026
Related information
Ihre Bereitstellung überwachen und verwalten

Übersicht

Non-Uniform Memory Access (NUMA) ist eine Multiprozessor-Speicherarchitektur, bei der der Speicher in Knoten unterteilt ist, die an bestimmte CPU-Sockel angeschlossen sind. Der Zugriff auf den Speicher auf dem lokalen NUMA-Knoten hat eine geringere Latenz als der Zugriff auf den Speicher auf einem entfernten Knoten. Wenn VM-vCPUs und ihr Speicher auf demselben NUMA-Knoten zusammenliegen, können Workloads eine geringere Speicherzugriffslatenz und eine bessere Leistung erzielen.

UMA und NUMA im Vergleich

  • UMA (Uniform Memory Access)-Hosts präsentieren den CPUs einen einzigen physischen Speicherknoten.
  • NUMA-Hosts stellen mehrere Speicherknoten bereit. CPUs haben eine geringere Latenz, wenn sie auf Speicher von ihrem lokalen Knoten zugreifen, als von entfernten Knoten.

Vorteile der optimierten NUMA-Platzierung

  • Verbesserte Anwendungsreaktionsfähigkeit und Workload-Durchsatz.
  • Höhere VM-Dichte pro Host, wodurch der Bedarf an zusätzlichen Hosts und die gesamten Infrastrukturkosten reduziert werden.

Einschränkungen

  • Wenn kein einzelner NUMA-Knoten auf einem Host über genügend freien Speicher für eine VM verfügt, startet XS9 die VM mit Speicher, der über mehrere Knoten verteilt ist, um den Start der VM zu ermöglichen.
  • Wenn der Speicher verteilt ist, verwendet die VM mehrere NUMA-Knoten (NUMA nodes > 1) und ist nicht NUMA-optimiert.
  • Leistungsverbesserungen variieren je nach Workload, Benchmark und CPU-Typ.

Überwachen und Fehler beheben

RRD-Metriken pro VM (standardmäßig deaktiviert) helfen bei der Überwachung des NUMA-Verhaltens und der vCPU-Planung.

Metriken

  • NUMA-Knoten (numa_nodes): Anzahl der von der VM verwendeten NUMA-Knoten. Wert 1 bedeutet optimiert; Werte größer als 1 bedeuten nicht optimiert.
  • Speicher-NUMA-Knoten X (memory_numa_node_X): Menge des VM-Speichers, der vom physischen NUMA-Knoten X zugewiesen wurde. Wert 0 bedeutet, dass kein Speicher von diesem Knoten stammt.
  • vCPUs ausführbar (beliebig) (runnable_any): Prozentsatz der Zeit, in der mindestens eine vCPU bereit ist, aber keine pCPU verfügbar ist. Dies ist ein früher Indikator für CPU-Konflikte.
  • vCPUs ausführbar (Summe) (runnable_vcpus): Erwartete prozentuale Verlangsamung über alle vCPUs aufgrund von Planungsverzögerungen.
  • NUMA nicht-affine vCPUs (numa_node_nonaffine_vcpus): Prozentsatz der Zeit, in der vCPUs auf pCPUs ausgeführt werden, die sich nicht im selben NUMA-Knoten wie der VM-Speicher befinden. Höhere Werte weisen auf eine erhöhte Speicherzugriffslatenz hin.
NUMA

Checkliste zur Fehlerbehebung

  1. Überprüfen Sie NUMA nodes, um zu sehen, wie viele NUMA-Knoten die VM verwendet.
  2. Überprüfen Sie vCPUs runnable any auf Planungskonflikte auf Domänenebene.
  3. Überprüfen Sie vCPUs runnable sum auf Planungsverzögerungen auf vCPU-Ebene.
  4. Überprüfen Sie NUMA non-affine vCPUs auf NUMA-Affinitätsverletzungen und damit verbundene Latenz.

Metriken aktivieren und Stichproben exportieren

RRD-Metriken pro VM sind standardmäßig deaktiviert. Um eine Metrik (z. B. runnable_any) für eine VM zu aktivieren und eine Stichprobe zu exportieren:
# Enable the data source for a VM
xe vm-data-source-record uuid=<vm-uuid> data-source=runnable_any

# Export sample RRD output
rrd2csv VM:AVERAGE::runnable_any

NUMA-Platzierung konfigurieren (xe CLI)

Die NUMA-Platzierungsoptimierung ist auf XS9-Hosts standardmäßig aktiviert. Es sind keine Maßnahmen erforderlich, um sie zu aktivieren.
Um die NUMA-Platzierungsoptimierung auf einem Host zu deaktivieren, legen Sie die NUMA-Affinitätsrichtlinie des Hosts auf any fest.
# View current policy
xe host-param-get uuid=<host-uuid> param-name=numa-affinity-policy

# Disable optimization
xe host-param-set uuid=<host-uuid> numa-affinity-policy=any

# Verify
xe host-param-get uuid=<host-uuid> param-name=numa-affinity-policy
Wenn standardmäßig aktiviert, ist der Richtlinienwert default_policy. Wenn deaktiviert, ist der Wert any.