Wie wirkt sich die NUMA-Architektur auf die Leistung von ActivePivot aus?

Question

Wir migrieren eine ActivePivot-Anwendung auf einen neuen Server (4 Sockets Intel Xeon, 512 GB Arbeitsspeicher). Nach der Bereitstellung haben wir unseren Anwendungsbenchmark gestartet (eine Mischung aus großen OLAP-Abfragen parallel zu Echtzeittransaktionen). Die gemessene Leistung ist fast doppelt so lang wie bei unserem vorherigen Server, der über ähnliche Prozessoren verfügt, aber doppelt so viele Kerne und doppelt so viel Arbeitsspeicher.

Wir haben die Unterschiede zwischen den beiden Servern untersucht, und es scheint, die große hat eine NUMA-Architektur (nicht einheitlichen Speicherzugriff). Jeder CPU-Socket befindet sich physisch in der Nähe von 1/4 des Speichers, aber weiter entfernt von dem Rest ... Die JVM, die unsere Anwendung ausführt, weist einen großen globalen Heap zu, es gibt einen zufälligen Bruchteil dieses Heaps auf jedem NUMA-Knoten. Unsere Analyse ist, dass das Speicherzugriffsmuster ziemlich zufällig ist und CPU-Kerne häufig Zeit verschwenden, auf entfernten Speicher zuzugreifen.

Wir freuen uns über mehr Feedback zum Einsatz von ActivePivot auf NUMA-Servern. Können wir ActivePivot-Cubes oder Thread-Pools konfigurieren, unsere Abfragen ändern, das Betriebssystem konfigurieren?

Answer 1

Peter beschrieb die allgemeinen JVM-Optionen, die heute verfügbar sind, um den Leistungseinfluss von NUMA-Architekturen zu reduzieren. Um es kurz zu halten, wird eine NUMA-fähige JVM den Heap in Bezug auf die NUMA-Knoten partitionieren, und wenn ein Thread ein neues Objekt erstellt, wird das Objekt im NUMA-Knoten des Kerns zugewiesen, der diesen Thread ausführt (wenn derselbe Thread später verwendet) es wird das Objekt im lokalen Speicher sein). Auch beim Komprimieren des Heapspeichers vermeidet die NUMA-fähige JVM das Verschieben großer Datenblöcke zwischen Knoten (und reduziert die Dauer von Stop-the-World-Ereignissen).

Also auf jeder NUMA-Hardware und für jede Java-Anwendung sollte die Option -XX: + UseNUMA wahrscheinlich aktiviert werden.

Aber für ActivePivot hilft das nicht viel: ActivePivot ist eine In-Memory-Datenbank. Es gibt Echtzeit-Updates, aber der Großteil der Daten befindet sich im Hauptspeicher für die Lebensdauer der Anwendung. Unabhängig von den JVM-Optionen werden die Daten unter NUMA-Knoten aufgeteilt, und die Threads, die Abfragen ausführen, greifen wahlfrei auf den Speicher zu. Wenn Sie wissen, dass die meisten Abschnitte der ActivePivot-Abfrage-Engine so schnell ausgeführt werden, wie Speicher abgerufen werden kann, ist die NUMA-Auswirkung besonders sichtbar.

Wie können Sie Ihre ActivePivot-Lösung auf einer NUMA-Hardware optimal nutzen?

Es gibt eine einfache Lösung, wenn die ActivePivot-Anwendung nur einen Bruchteil der Ressourcen verwendet (wir stellen fest, dass dies häufig der Fall ist, wenn mehrere ActivePivot-Lösungen auf demselben Server ausgeführt werden). Zum Beispiel eine ActivePivot-Lösung, die nur 16 von 64 Kernen und 256 GB eines TeraByte verwendet. In diesem Fall können Sie den JVM-Prozess selbst auf einen NUMA-Knoten beschränken.

Unter Linux Sie den JVM Start mit der folgenden Option Präfix (http://linux.die.net/man/8/numactl):

numactl --cpunodebind=xxx 

Wenn der gesamte Server zu einer ActivePivot Lösung gewidmet ist, können Sie die ActivePivot verteilte Architektur nutzen, um die Daten zu partitionieren. Wenn 4 NUMA-Knoten vorhanden sind, starten Sie 4 JVMs, die 4 ActivePivot-Knoten hosten, von denen jeder an seinen NUMA-Knoten gebunden ist. Mit dieser Bereitstellung werden Abfragen auf die Knoten verteilt, und jeder Knoten führt seinen Anteil an der Arbeit mit maximaler Leistung innerhalb des richtigen NUMA-Knotens aus.

Answer 2

Sie können versuchen, -XX:+UseNUMA

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

Verwendung Wenn dies nicht das gewünschte Ergebnis nicht nachgeben erwarten Sie vielleicht taskset zu benutzen, haben eine JVM auf einen bestimmten Sockel zu verriegeln und den Server effektiver in vier Maschinen brechen mit jeweils einer JVM.

Ich habe beobachtet, dass die Maschine mit mehr Sockets einen langsameren Zugriff auf ihren Speicher (sogar ihren lokalen Speicher) und wie immer geben Sie die Performance-Gewinne, die Sie wollen, als Ergebnis.