NUMA-Serverarchitektur: Aufbau und Performancefaktoren

Die NUMA-Architektur (Non-Uniform Memory Access) hat das Design moderner Server grundlegend verändert. Mit dem Wachstum der Kernanzahl, dem Übergang zu Multisockel-Setups und immer komplexer werdenden CPU-Topologien ist der gleichmäßige Zugriff auf den gesamten Speicher Geschichte. Stattdessen bestimmt heute die NUMA-Architektur, wie schnell Prozesse auf Daten zugreifen können - und das kann die Serverleistung dramatisch beeinflussen.

Was ist NUMA und warum wurde es eingeführt?

NUMA steht für "Non-Uniform Memory Access". In diesem Architekturmodell hängt die Zugriffszeit auf den Arbeitsspeicher davon ab, wo sich die Speicherzelle physisch im Verhältnis zum CPU-Kern befindet. Anders als bei UMA-Systemen (Uniform Memory Access) ist der Speicher nicht mehr für alle Kerne gleich schnell erreichbar.

Früher basierten Server auf UMA: Ein oder mehrere Prozessoren griffen mit ähnlicher Latenz auf einen gemeinsamen Speichercontroller zu. Das funktionierte, solange Kerne und Speicher überschaubar blieben. Mit steigenden Anforderungen und Multisockel-Architekturen wurde der einzelne Speichercontroller jedoch zum Flaschenhals.

NUMA löst dieses Problem, indem es den Speicher in mehrere Knoten aufteilt. Jeder NUMA-Knoten besteht meist aus einem Prozessor (bzw. Kern-Gruppe) und einem lokalen Speicherbereich. Der Zugriff auf den lokalen Speicher ist schneller als der auf entfernte Knoten, da letzterer über Interconnects wie QPI oder UPI erfolgen muss.

Für Hardware ist das logisch: Die CPU kann lokal schnell arbeiten und die Architektur skaliert besser auf viele Sockel. Deshalb ist NUMA heute Standard in modernen Serverplattformen - vor allem bei Systemen mit zwei oder mehr Prozessoren.

Die Komplexität entsteht jedoch auf Softwareseite: Betriebssystem und Anwendungen sehen den Speicher weiterhin als einheitlichen Adressraum, obwohl er physisch verteilt ist. Wird ein Thread auf einem Knoten ausgeführt, die Daten liegen aber auf einem anderen, entstehen zusätzliche Verzögerungen - oftmals unsichtbar in Standardmetriken, aber mit gravierenden Folgen für die Performance.

NUMA vs. UMA: Die entscheidenden Unterschiede für Server

Der Unterschied zwischen UMA und NUMA ist fundamental: In UMA-Systemen greifen alle Kerne mit gleicher Latenz auf den gesamten Speicher zu. Die Programmierung ist einfach und das Verhalten vorhersehbar.

NUMA hingegen verteilt den Speicher auf mehrere Knoten. Jeder Prozessor arbeitet am schnellsten mit seinem lokalen Speicher, Zugriffe auf entfernte Speicherbereiche sind deutlich langsamer - teils um Dutzende Prozentpunkte bei der Latenz. Für Serveranwendungen, bei denen konstante Antwortzeiten wichtiger sind als reine Rechenleistung, ist das kritisch. Datenbanken, Caching-Systeme, Messaging-Broker und Virtualisierung setzen auf schnellen Speicherzugriff. Bei NUMA kann die Performance jedoch abrupt einbrechen, wenn Threads und Daten nicht optimal platziert sind.

In Multisockel-Konfigurationen ist UMA heute praktisch nicht mehr realisierbar - die Hardware-Limits machen es zu teuer. NUMA ist daher der Industriestandard, bringt aber neue Anforderungen an das Verständnis der Architektur mit sich.

Speicherzugriff in NUMA-Systemen

In NUMA-Systemen hängt die Geschwindigkeit des Speicherzugriffs davon ab, wo die Daten liegen. Jeder CPU-Kern ist einem NUMA-Knoten zugeordnet, der über einen eigenen Speichercontroller und einen lokalen Speicherbereich verfügt.

Lokaler Speicherzugriff erfolgt direkt und ist schnell. Liegen die Daten jedoch auf einem anderen Knoten, muss der Zugriff über Interconnects wie QPI oder UPI erfolgen. Das erhöht die Latenz und senkt die effektive Bandbreite. Für den Programmcode sieht das alles gleich aus - die Unterschiede sind rein hardwareseitig und für Anwendungen meist unsichtbar.

Das Betriebssystem versucht, durch Speicher- und Threadbindung die Locality zu optimieren. Doch bei Belastung, Thread-Migration oder Prozessstarts kann diese Zuordnung schnell verloren gehen. Auch CPU-Caches können die Problematik nur kurzfristig kaschieren; unter Last kommt es immer häufiger zu langsamen, entfernten Speicherzugriffen.

NUMA-Architektur und CPU-Topologie

Die wirkliche Herausforderung bei NUMA liegt in der CPU-Topologie. Moderne Prozessoren bestehen aus mehreren Kernen, Speichercontrollern und Interconnects. In Multisockel-Systemen bildet jeder Sockel einen eigenen NUMA-Knoten mit eigenen Ressourcen - verbunden durch schnelle, aber nicht latenzfreie Interconnects.

Sogar innerhalb eines Sockels kann es mehrere NUMA-Domains geben, etwa durch Chiplet-Designs mit unterschiedlichen Wegen zum Speichercontroller. Das erhöht die Komplexität weiter. Das Betriebssystem muss diese Topologie kennen, aber in der Praxis wird sie selten optimal genutzt. Dynamische Vorgänge wie Thread-Migration oder Änderungen der Systemlast bringen zusätzliche Unsicherheiten.

Die Konsequenz: Mehr Sockel und Kerne bedeuten mehr Ressourcen, aber auch mehr potenzielle Latenzprobleme. Die tatsächliche Performance hängt davon ab, wie gut Anwendungen und das OS die NUMA-Topologie ausnutzen.

Warum NUMA die Serverperformance beeinträchtigt

NUMA führt zu Leistungseinbußen, weil die Modelle der meisten Serveranwendungen nicht auf verteilten Speicher ausgelegt sind. Hauptgrund für Performanceverluste ist der Verlust der Datenlokalität: Threads und ihre Daten befinden sich auf unterschiedlichen NUMA-Knoten, was die Latenz erhöht und die CPU-Auslastung verringert. Die Folge: Die Serverleistung sinkt trotz scheinbar hoher CPU-Last.

Ein weiteres Problem ist die Konkurrenz um Interconnects. Wenn mehrere Threads gleichzeitig auf entfernten Speicher zugreifen, wird die Bandbreite zum Flaschenhals und die Latenz steigt nichtlinear. Auch das Verhalten des Betriebssystem-Schedulers kann zu Problemen führen, wenn Threads aus Gründen der CPU-Balance auf andere Knoten verschoben werden, die Daten aber auf dem alten Knoten verbleiben.

Besonders kritisch wird das bei Anwendungen mit vielen Threads und gemeinsam genutztem Speicher - etwa bei Task-Queues, Shared Caches oder globalen Datenstrukturen. Mit jedem weiteren Sockel steigt die Wahrscheinlichkeit für entfernte Zugriffe.

NUMA in Multiprozessorsystemen: Wo die Probleme beginnen

In Multisockel-Systemen verstärken sich die NUMA-Probleme. Jeder zusätzliche Sockel bringt mehr Kerne und Speicher, aber auch mehr potenzielle Wege für entfernte Speicherzugriffe. Die Architektur gleicht einem komplexen Netz, in dem jede Fehlplatzierung von Threads oder Daten zu drastischen Performanceeinbußen führen kann.

Interconnects zwischen Prozessoren werden schnell zum Engpass, insbesondere bei hoher Last. Anwendungen, die nicht NUMA-bewusst entwickelt sind, profitieren kaum von zusätzlicher Hardware - oder verlieren sogar an Performance. Besonders problematisch ist das bei gemeinsam genutzten Servern, Virtualisierung oder bei Anwendungen mit hoher Synchronisation.

Der sogenannte "Ping-Pong-Effekt" durch häufige Cache-Line-Übertragungen zwischen Sockeln ist eine zusätzliche Herausforderung, die die Skalierbarkeit stark einschränkt.

NUMA, Speicherzugriff und Latenz: Warum hohe Latenz Skalierung verhindert

Die Latenz beim Speicherzugriff ist der entscheidende Faktor für die Performance in NUMA-Systemen. Selbst wenn die Bandbreite ausreichend ist, kann eine erhöhte Latenz den Vorteil zusätzlicher Kerne oder mehr RAM zunichtemachen. Tausende Threads greifen gleichzeitig auf den Speicher zu, und jede Verzögerung summiert sich in den Antwortzeiten der Anwendungen.

Vor allem Systeme mit starker Synchronisation, wie Datenbanken oder verteilte Caches, leiden unter NUMA-Latenz. Standardmetriken zeigen diese Probleme oft nicht, sodass die Ursache meist erst spät erkannt wird.

Das Ergebnis: Mehr Hardware bringt nicht automatisch bessere Performance, solange Threads und Daten nicht optimal verteilt sind.

Typische Fehler von Betriebssystemen und Anwendungen im Umgang mit NUMA

• Aggressive Thread-Migration: Scheduler verteilen Threads auf verschiedene Kerne, ohne die Speicherlokalität zu berücksichtigen. Das führt zu erhöhten entfernten Zugriffen und mehr Latenz.
• Fehler bei der Initialisierung: Anwendungen reservieren beim Start den Großteil ihres Speichers, bevor die Threads auf Kerne verteilt sind. Dadurch landet der Speicher auf einem Knoten, wird aber von Threads auf anderen Knoten genutzt.
• Ignorieren von NUMA in Multithreading: Gemeinsame Datenstrukturen und Threadpools werden erstellt, ohne die physische Speicherverteilung zu berücksichtigen. Das führt zu ständiger Interknoten-Konkurrenz.
• Probleme bei Virtualisierung und Containern: Gastsysteme erkennen die NUMA-Topologie des Hosts nicht korrekt und verteilen Ressourcen ineffizient.
• Monitoring-Lücken: Viele Monitoring-Tools erfassen NUMA-bedingte Latenzen nicht, sodass Administratoren die eigentliche Fehlerquelle nicht erkennen.

Wann NUMA sinnvoll ist - und wann nicht

NUMA ist kein reines Problem, sondern in bestimmten Szenarien ein echter Gewinn. Aufgaben, bei denen sich Daten und Berechnungen klar aufteilen lassen (z. B. wissenschaftliches Rechnen, Rendering oder sehr große Datenbanken mit gezielter Segmentierung), profitieren deutlich von NUMA.

NUMA ist dann schädlich, wenn die Arbeitslast schlecht lokalisiert ist - etwa bei Webservices mit gemeinsamen Caches, Messaging-Systemen oder Plattformen mit starker Synchronisation. Auch Virtualisierung und Containerisierung machen es schwer, die Vorteile von NUMA zu nutzen, da die Locality verloren gehen kann.

Für Anwendungen, bei denen minimale und stabile Latenz entscheidend ist, stellt NUMA ein erhebliches Risiko dar. Selbst wenn die durchschnittliche Performance stimmt, können gelegentliche Latenzspitzen das System für kritische Dienste ungeeignet machen.

Fazit

NUMA ist ein unvermeidlicher Schritt in der Entwicklung moderner Serverarchitekturen. Ohne NUMA wäre das Skalieren von Multisockel-Systemen auf viele Kerne und große RAM-Mengen nicht möglich. Mit dieser Hardware-Evolution kommen jedoch neue Herausforderungen: versteckte und schwer zu diagnostizierende Performance-Probleme.

NUMA bricht mit der Vorstellung von Speicher als gleichmäßig zugänglicher Ressource. Die Zugriffszeiten variieren je nach CPU-Topologie, Datenverteilung und Scheduler-Verhalten. Wer diese Realität ignoriert, riskiert Latenzprobleme und Leistungseinbußen, besonders bei universellen Server-Workloads wie Virtualisierung, Microservices und synchronisierenden Datenbanken.

NUMA ist kein grundsätzliches Problem, sondern ein Werkzeug. Mit bewusster Architektur, Kenntnis der Topologie und gezielter Steuerung von Speicher und Threads lässt sich das Potenzial moderner Server optimal nutzen. Gerade in Hochlastszenarien ist ein tiefes Verständnis von NUMA heute keine Option mehr, sondern Voraussetzung für stabile und leistungsfähige Systeme.