Java CMS wird ignoriert und wird stattdessen voll GC

9

Ich verwende einen Java-Server, der CMS für den Tenure-Collector verwendet. Wenn ich unter Last-Tests laufe, sehe ich junge Kollektionen etwa alle 1s und alle etwa 5m (gleichzeitig). Das ist gut.

Wenn ich mit echtem Traffic von etwa 1/2 Kapazität laufe, bekomme ich ungefähr alle 4s junge Kollektionen und alle 7m (! parallel, Stoppt die Welt!). Warum entscheidet sich die JVM dafür, vollständige Stop-the-World-Sammlungen zu erstellen, statt den CMS-Kollektor zu verwenden?

Aus dem gc.log können Sie sehen, dass der "Full GC" ausgeführt wird und über 3 Sekunden dauert, um abzuschließen. Es gibt hier keinen Fehler im gleichzeitigen Modus. Nichts fordert explizit eine Sammlung an.

%Vor%

Hier sind die JVM-Flags:

%Vor%     
Brian White 19.04.2011, 16:02
quelle

2 Antworten

2

Wenn Ihr Survivor Space nicht groß genug ist, kann ein Full GC ausgelöst werden. (Es scheint sich über die Überlebensrate zu beschweren)

Entweder musst du deine Überlebensrate verringern oder es ist wahrscheinlich eine bessere Lösung, deine NewSize zu erhöhen, sodass weniger Objekte aus dem Edenraum überleben. Ich habe einen eden Speicherplatz von 6 GB;)

    
Peter Lawrey 19.04.2011 16:11
quelle
1

Ich erinnere mich, dass ich letztes Jahr ein ähnliches Phänomen beobachtet habe, als ich einen großen Haufen abstimmte, um eine vollständige GC zu vermeiden. Ich denke, dass Sie vielleicht die Größe von Eden verringern möchten. Das ist ziemlich groß im Vergleich zu der Generation mit fester Anstellung.

Was meiner Meinung nach passieren könnte, ist, dass mehr Eden mit deinem Verkehr mit halber Geschwindigkeit auf einmal "alt" werden als mit voller Geschwindigkeit (wo sie nicht überleben). Was bedeutet, dass mehr davon gleichzeitig in den Ruhestand gehen muss. Und wenn es zu diesem Zeitpunkt nicht passt, kann es einen vollständigen GC auslösen, um Platz zu schaffen.

Als Referenz hier ist, was wir jetzt für 6 GB bis 24 GB Heaps verwenden:

%Vor%

Es ist schon ziemlich ähnlich zu dir. Das Schöne an der Verwendung aller Kennzahlen ist, dass Sie die Größe des Heapspeichers leicht ändern können und (im Allgemeinen) entsprechend skaliert werden. Eine andere Anmerkung ist, dass -XX:+UseCompressedOops typischerweise 40% weniger Speicher verwenden kann, indem die 64-Bit-Adressierung auf 32-Bit reduziert wird (funktioniert nur bis zu 32 GB).

    
WhiteFang34 19.04.2011 19:02
quelle

Tags und Links