Für den Kontext eines weichen Echtzeitsystems, das nicht länger als 200 ms pausieren sollte, suchen wir nach einer Möglichkeit, eine Vorwarnung zu erhalten, bevor ein vollständiger GC bevorsteht. Wir wissen, dass wir es möglicherweise nicht vermeiden können, aber wir würden gerne zu einem anderen Knoten wechseln, bevor das System zum Stillstand kommt.
Wir konnten uns ein Schema ausdenken, das uns vor einem bevorstehenden vollständigen GC warnt, das dazu führen könnte, dass das System für einige Sekunden zum Stillstand kommt (was wir vermeiden müssen).
Was wir erreicht haben, beruht auf der Statistik der kostenlosen CMS-Listen: -XX:PrintFLSStatistics=1 . Dadurch wird die Statistik der freien Liste nach jedem GC-Zyklus in das GC-Protokoll gedruckt, einschließlich des jungen GC, sodass die Informationen in kurzen Intervallen verfügbar sind und in Intervallen mit hoher Speicherzuweisungsrate noch häufiger angezeigt werden. Es kostet wahrscheinlich ein wenig in Bezug auf die Leistung, aber unsere Arbeitsannahme ist, dass wir es uns leisten können.
Die Ausgabe in das Protokoll sieht folgendermaßen aus:
%Vor%Insbesondere ist die maximale freie Chunk-Größe 382064598 Wörter. Bei 64-Bit-Worten sollte das knapp unter 2915 MB liegen. Diese Zahl ist mit einer Rate von ungefähr 1 MB pro Stunde sehr langsam gesunken.
Es ist unser Verständnis, dass, solange die maximale freie Chunk-Größe größer ist als die der jungen Generation (unter der Annahme, dass keine humose Objekt-Zuweisung vorliegt), jede Objekt-Promotion erfolgreich sein sollte.
Vor kurzem haben wir mehrere Tage lang Stresstests durchgeführt und festgestellt, dass CMS maximale Chunk-Größen von über 94% des gesamten Bereichs der alten Region beibehalten konnte. Die maximale freie Chunk-Größe scheint mit einer Rate von weniger als 1 MB / Stunde zu sinken, was in Ordnung sein sollte - dementsprechend werden wir nicht in absehbarer Zeit auf volle GC treffen, und die Server werden wahrscheinlich wegen Wartungsarbeiten weniger aktiv sein häufiger als vollständige GC kann auftreten.
In einem früheren Test konnten wir das System zu einer Zeit, in der das System weniger effizient war, für gut 10 Stunden laufen lassen. Während der ersten Stunde ist die maximale freie Chunk-Größe auf 100 MB gesunken, wo sie für mehr als 8 Stunden blieb. Während der letzten 40 Minuten des Laufs ging die maximale freie Chunk-Größe stetig in Richtung 0 zurück, als ein vollständiger GC auftrat - dies war sehr ermutigend, denn für diese Auslastung schien es uns möglich zu sein, einen 40-minütigen Fortschritt zu erzielen Warnung (wenn die Chunk-Größe einen stetigen Rückgang in Richtung 0 begann).
Meine Frage an Sie : Unter der Annahme, dass dies alles eine längere Spitzenbelastung widerspiegelt (Arbeitsbelastung zu einem bestimmten Zeitpunkt in der Produktion wird nur geringer sein), klingt das nach einem gültigen Ansatz? Bis zu welchem Grad der Zuverlässigkeit sollten Sie in der Lage sein, sich auf die maximale Statistik für die freie Chunk-Größe aus dem GC-Protokoll zu verlassen?
Wir sind auf jeden Fall offen für Vorschläge, bitten Sie aber, sie auf Lösungen zu beschränken, die auf HotSpot verfügbar sind (No Azul für uns, zumindest für den Moment). Auch G1 allein ist keine Lösung, es sei denn, wir können eine ähnliche Metrik erstellen, die uns vor Full GCs oder GCs, die unsere SLA signifikant überschreiten, warnt (und diese können gelegentlich auftreten).
Ich poste hier relevante Auszüge aus einer sehr aufschlussreichen und ermutigenden Antwort von Jon Masamitsu von Oracle, die ich von der HotSpot GC Mailingliste ([email protected]) bekommen habe - er arbeitet an HotSpot, Das sind wirklich sehr gute Nachrichten.
Auf jeden Fall bleibt die Frage vorerst offen (ich kann mich nicht dafür aussprechen, eine E-Mail zu schreiben :-)), also fügen Sie bitte Ihre Vorschläge hinzu!
Formatierung: Zitate aus dem ursprünglichen Beitrag sind stärker eingerückt als Jons Antwort.
Es ist unser Verständnis, solange die maximale freie Chunk-Größe ist größer als die junge Generation (unter der Annahme, kein humungous Objekt Allokation) sollte jede Objektwerbung gelingen.
Dies ist weitgehend richtig. Es gibt Umstände unter was ein von der jungen Generation in die CMS-Generation befördertes Objekt erfordert mehr Platz in der CMS-Generation als in der jungen Generation. Ich nicht denke, dass dies in einem wesentlichen Ausmaß geschieht.
Das obige ist sehr ermutigend, da wir definitiv etwas Ersatzspeicher zum Schutz vor den seltenen Fällen widmen können, die er beschreibt, und es hört sich so an, als würden wir es anders machen.
& lt; - Schnipsel - & gt;
Meine Frage an Sie : unter der Annahme, dass alles einen längeren Höhepunkt widerspiegelt Workload (Arbeitsbelastung zu jedem beliebigen Zeitpunkt in der Produktion wird nur niedriger sein), klingt das nach einem gültigen Ansatz? Bis zu welchem Grad Zuverlässigkeit, denken Sie, wir sollten auf das Maximum zählen können freie Chunk-Size-Statistik aus dem GC-Log?
Die maximale Größe des freien Chunks ist genau zu der Zeit, zu der GC es druckt, aber es kann alt sein, wenn Sie es lesen und Ihre Entscheidungen treffen.
Für unsere Workloads ist diese Metrik eine sehr langsame Abwärtsspirale, also wird uns ein bisschen Langsamkeit nicht schaden.
& lt; - Schnipsel - & gt;
Wir sind definitiv offen für Vorschläge, aber fordern Sie sie auf beschränkt auf Lösungen, die auf HotSpot verfügbar sind (No Azul für uns zumindest zur Zeit). Auch G1 allein ist keine Lösung, wenn wir nicht auf die Idee kommen Eine ähnliche Metrik, die uns vor Full GCs warnt, oder alle GCs, die unsere SLA deutlich übersteigen (und diese können gelegentlich auftreten).
Ich denke, dass die Verwendung der maximalen freien Chunk-Größe als Metrik gut ist Wahl. Es ist sehr konservativ (was klingt wie du willst) und nicht Gegenstand von ungeraden Mischungen von Objektgrößen.
Für G1 könnte man die Anzahl der komplett freien Regionen verwenden. Ich weiß nicht, ob es in irgendeinem der Protokolle gegenwärtig gedruckt wird, aber es ist wahrscheinlich eine Metrik, die wir beibehalten (oder könnten). Wenn die Anzahl der völlig frei ist Regionen nimmt mit der Zeit ab, es könnte signalisieren, dass ein vollständiger GC kommt.
Jon
Danke Jon!
Teile und erobere!
Ihr System benötigt viel Speicher und muss sehr reaktionsschnell sein. Entwerfen Sie die Architektur Ihres Systems neu, um einen Stand zu erreichen.
Identifizieren Sie die kritische Echtzeitaufgabe und erstellen Sie mit ihren Geschäftsregeln einen Java-Prozess dafür. Und nutzte jede nicht-konventionelle Programmierpraxis darauf, ist die Idee nicht davon abhängig, dass der GC den Speicher sauber hält. Denk darüber nach und sei kreativ.
Erstellen Sie nun andere Ebenen und Prozesse, um den Rest zu bearbeiten und erstellen Sie den Pipe-Code, um alles zu verbinden.
Und sogar Sie können das Leben des Echtzeitprozesses planen oder ihre Antwortzeit überprüfen, um sie zu töten und eine neue neue zu erstellen. Aber ich kann erwarten, dass Sie es nicht töten müssen, um es hoch zu halten.
Viel Glück!
Tags und Links java garbage-collection performance real-time