Vertikale Skalierung von Java Echtzeitanwendung

Mit GC-Tuning bin ich erfolgreich in der Lage Leistung für Java-Echtzeit-Anwendungen zu erhalten und erkennbar GC Pausen zu vermeiden. Aber das gilt bis zu ~ 20 GB Heap-Speicherplatz.Vertikale Skalierung von Java Echtzeitanwendung

Die Senkung der Hardwarekosten hat sogar 100GB RAM-Rechner erschwinglich gemacht. Aber immer noch mit Java aufgrund von GC-Pausen, können höhere Heap-Größen wie 50 GB Sie in regelmäßigen Abständen in Albtraum versetzen.

Ich verstehe, dass es Optionen wie Off-Heap und Distributed-Heap gibt. Aber, Off-Heap hat den Nachteil der Se/Derialisierung und verteilter Heap auf der Hand erhöht die Wartungskosten. Des Weiteren sind Sie in verteilten Haufen tatsächlich nicht vollständig RAM verwendet (etwa 64 GB), die häufig in diesen Tagen als Rohstoff immer.

Um also das Potenzial von RAM voll auszuschöpfen, was sind die guten Lösungen für die vertikale Skalierung von Java-Anwendungen?

Quelle

2013-07-16 sky

"Java Echtzeit-Anwendung" <= lol wut? Sie sollten Java wirklich nicht für eine Echtzeitanwendung verwenden. Es ist einfach nicht dafür gemacht. –

@stonedsquirrel - das ist ein ziemlich engstirniger Blick auf den JVM. Es gibt jvms, die auf Echtzeitanwendungen ausgerichtet sind. – jtahlborn

Ich nehme an, Sie beziehen sich auf das Orakel jvm, das ziemlich auf "allgemeine Zwecke" ausgerichtet ist. hast du jvms angeschaut, die speziell für große erinnerungen wie azul entwickelt wurden? – jtahlborn

Ich arbeite an einer primitiven Sammlung Bibliothek namens Banana. Banana spricht diese genauen Probleme an. Es unterstützt LinkedLists, HashMaps und möglicherweise auch andere Datenstrukturen bald ohne den Aufwand von N Objekte zu halten. Grundsätzlich - der gesamte Speicher kann in einem int [] Array (oder vielen) liegen.

Während ich noch nicht offiziell es freigegeben wird, ist für die meisten es gut getestet und ich habe es lief bereits erfolgreich auf Server mit 144 GB RAM, ohne GC Pausen schnell und konsistente Leistung.

Schauen Sie sich this Hash-Karte-Benchmark an, um eine Idee zu erhalten, wie man Banana verwendet, um Daten zu speichern und wie gut sie vertikal skaliert werden.

https://github.com/omry/banana/wiki/Long-to-fixed-size-object-benchmark

die wiki für weitere Informationen anzeigen.

Quelle

2013-07-17 06:07:46

Danke für die Eingabe. Wird es durchlaufen. Ist dies kostenlos oder hat eine Lizenz für kommerzielle Nutzung. – sky

frei wie in Banane (BSD-Lizenz). –

Grundsätzlich möchte ich sehen, dass es verwendet wird, und hoffentlich einige Bestätigung von Benutzern, dass dies in der Tat ist so fantastisch, wie ich denke, und möglicherweise auch allgemeine Open-Source-Güte wie Fehlerberichte und Code-Beiträge. –

Garbage Collection Zeit ist eine Funktion der Anzahl der Live-Objekte in der Halde. Dies bedeutet, dass, wenn Ihre Zuweisungsrate sehr hoch ist, aber die Anzahl der Live-Objekte ist immer niedrig ist, können Sie so viel RAM verwenden, wie Sie wollen, ohne nennenswerte Pausen zu haben.

Diese Aussage gilt besonders für den Troughput Collector (-XX:+UseParallelOldGC).

Wenn Sie CMS verwenden, möchten Sie wahrscheinlich den inkrementellen Modus (-XX:+CMSIncrementalMode) überprüfen. Es wird kleinere CMS-Zyklen auslösen, um einen kleineren Teil Ihres Heaps zu säubern, während Sie Ihre Hardware und ohne STW-Pausen nutzen.

Wenn CMS keine Option ist, sollten Sie sich G1 (-XX:+UseG1GC) ansehen, einen neuen Garbage Collector, der für große Heaps entwickelt wurde. Das Prinzip ist: Säubern Sie nur einige Bereiche des Heaps bei jedem Zyklus, aber stellen Sie sicher, dass diese Bereiche viele tote Objekte enthalten (schnelle Gewinne).

Hoffe, dass hilft!

Quellen:

Quelle

2013-07-17 11:52:47

habe ich einige der Forschung auf Heap-Größe von JVM Skalierung. Sie können weitere Details here und here lesen.

Hauptschlussfolgerung: junge GC-Pause haben zwei konstante und variable Komponenten.

Konstante Komponente hängt von der Größe des alten Speicherplatzes ab und für 64GiB erwarte ich 80ms-120ms (abhängig von der Hardware).

Variable Komponente hängt vom Überstehen von Objekten im jungen Raum ab (ändert sich also von Sammlung zu Sammlung). Es ist wirklich anwendungsspezifisch, aber Sie können es normalerweise verringern, indem Sie jungen Platz (auf Kosten von häufigeren Pausen) reduzieren.

In Ihrem Fall für 4 GiB jungen Raum haben Sie 500ms. Unter der Annahme, dass die variable Komponente 400ms beträgt, sollten Sie, wenn Sie den jungen Speicherplatz auf 1 GiB reduzieren, ca. 200ms Pausen haben (aber 2 mal pro Sekunde).

Ein anderer Ansatz ist es, mehr CPU-Kerne zu verwenden, junge GC parallel extremely well.

Quelle

2013-07-19 16:43:17

G1 und Shenandoah (experimentelle) Garbage Collectors bieten eine große Elastizität und entsperren die vertikale Skalierung für Java-Anwendungen, um die Speicherauslastung entsprechend der aktuellen Auslastung zu optimieren. Weitere Einzelheiten, wie es funktioniert sind in dem Artikel Minimize Java Memory Usage with the Right Garbage Collector

Quelle

2017-11-21 20:41:44 Ruslan

Vertikale Skalierung von Java Echtzeitanwendung

Antwort

Verwandte Themen