JVM genug Speicher, aber Frequenz voll gc

JVM Optionen: -Xms512M -Xmx512M -XX: PermSize = 70M -XX: MaxPermSize = 70MJVM genug Speicher, aber Frequenz voll gc

jstat -gc 8260 5000

S0C: 512,0 S1C: 512,0 S0U: 0,0 S1U: 0,0 EC: 174080,0 EU: 0.0 OC: 349696,0 OU: 45191,1 PC: 71.680,0 PU: 34.882,2 YGC: 2.216.225 YGCT: 6754,909 FGC: 2.216.144 FGCT: 160651,466 GCT: 167406,375

S0C: 512,0 S1C: 512,0 S0U: 0,0 S1U: 64,0 EC: 174080,0 EU: 0,0 OC: 349696,0 OU: 45187,3 PC: 71680,0 PU: 34882,2 YGC: 2216253 YGCT: 6755,047 FGC: 2216172 FGCT: 160653,488 GCT: 16740 8,535

S0C: 512,0 S1C: 512,0 S0U: 0.0 S1U: 128,0 EC: 174080,0 EU: 0.0 OC: 349696,0 OU: 45189,6 PC: 71.680,0 PU: 34.882,2 YGC: 2.216.281 YGCT: 6755,180 FGC: 2.216.200 FGCT: 160655,542 GCT: 167410,721

S0C: 512,0 S1C: 512,0 S0U: 0.0 S1U: 0,0 EC: 174080,0 EU: 1.775,6 OC: 349696,0 OU: 45187,3 PC: 71.680,0 PU: 34.882,2 YGC: 2.216.308 YGCT: 6755,309 FGC: 2.216.227 FGCT: 160657,627 GCT: 167412,936

S0C: 512,0 S1C: 512,0 S0U: 128,0 S1U: 0,0 EC: 174080,0 EU: 0.0 OC: 349696,0 OU: 45187,3 PC: 71.680,0 PU: 34.882,2 YGC: 2.216.336 YGCT: 6755,444 FGC: 2.216.255 FGCT: 160659,701 GCT: 167415,146

Warum ist JVM frequency full gc passiert?

Quelle

2016-10-08 vzyh

Das Programm erstellt einen UDP-Server, der Pakete empfängt und analysiert (weniger als 1024 Bytes). ** Nach 3-5 Tagen funktioniert das gut, das passiert. – vzyh

Wenn Heap- und Stack-Speicher gut aussieht, versuchen Sie Speicherverlust über "Direct Memory" zu finden. In meinem Fall wurde ein Teil von Netty5-ByteBuf nicht veröffentlicht.

Quelle

2016-11-01 08:54:31 vzyh

Es ist schwer zu sagen, aber eine mögliche Erklärung ist, dass Sie immer wieder sehr große Arrays zuweisen und verwerfen.

Wenn ich die Statistiken richtig interpretiere, ist der Eden-Raum 174MB, die Survivor-Räume sind 0,5MB, und der Alte Raum ist 349MB. Wenn Sie ein Array zuweisen, das zu groß ist, um es in den Eden-Raum zu legen, wird es direkt dem Alten Raum zugewiesen. Wenn der Alte Raum gefüllt wird, kann dies einen vollständigen GC auslösen.

Wie groß ist "groß"? Nun, es ist kompliziert, denn es gibt auch das Problem des TLAB und seine Größe, die -XX:PretenureSizeThreshold Option und Unterschiede zwischen verschiedenen Arten von GC. Lesen Sie "Java Garbage Collection Distilled" von Martin Thompson, um mit den Problemen zu beginnen.

Wenn dies nicht das Problem ist, dann müssen Sie eine tiefere Untersuchung dessen durchführen, was in Ihrem Heap passiert. Finde heraus, was die Mischung von Objekten ist, ihre Raten und Verteilungsmuster/Disposition, etc. um herauszufinden, warum so viele im Alten Raum landen. Die In-Memory-Datenstrukturen über jene drei bis fünf Tagen der Operation

Nach 3-5 Tagen funktioniert gut, dies geschieht

Das vorschlagen neigt, dass etwas in der Anwendung aufbaut. Untersuche dieses Szenario.

Quelle

2016-10-08 04:25:40

Danke für Ihre Antwort. Ich bin sicher, dass es keine "großen" Arrays gibt, das Programm erstellt einen UDP-Server, der Pakete empfängt und analysiert (weniger als 1024 Bytes). ** Nach 3-5 Tagen in Folge ** ist das passiert. – vzyh

Verwenden Sie 'ArrayList' oder' StringBuilder'? Oder eine andere Datenstruktur, die Arrays hinter den Kulissen verwendet? –

Kann haben, aber es könnte kein 'großes' Array geben, denn nur nach 3-5 Tagen funktioniert das gut (das Programm erhält 10-20 kleine Pakete pro Sekunde, die voneinander getrennt sind). – vzyh

Ihre Überlebensräume sind sehr klein. Nur 512 KB. Wenn der Survivor-Raum bei einer Säuberung des Eden-Space voll wird, löst er einen Full-GC aus.

Da Ihre Eden Räume ~ 300 x größer sind, wäre ich überrascht, wenn sie sich nicht füllen würden.

Ich würde überprüfen, dass Sie nicht viele sehr kurzlebige Objekte erstellen, weshalb die JVM denkt, dass kaum etwas überlebt.

Zum Beispiel, sehen Sie, wenn Sie Ihr UDP-Paket analysieren/verarbeiten können, ohne Objekte zu erstellen.

Quelle

2016-10-08 15:18:56

Ich habe die Option survivorRatio nicht festgelegt, die tatsächliche Größe wurde von JVM bestimmt. Und ich versuche entfernt "-Xms512M -Xmx512M -XX: PermSize = 70M -XX: MaxPermSize = 70M" -Optionen, dann die Größe geändert, um 1024, bis jetzt 2 Tage funktioniert gut, ich werde Update bei zukünftigen – vzyh

@ vzyh Einstellung Tuning-Parameter haben oft unbeabsichtigte Folgen, die auf eine seltsame Interaktion zurückzuführen sein können. Hinweis: Wenn Sie nicht nur 2 GB auf Ihrem Computer haben, haben Sie die Heap-Größe erhöht, die standardmäßig auf 1/4 des Hauptspeichers eingestellt ist. –

Nach Einstellung -Xmn512m -XX: SurvivorRatio = 8, am Anfang scheint in Ordnung, S0 und S1 beide 40M Eden Raum 400M, aber einen Tag später S0 und S0 auf 16M geändert und Eden Raum auf 480M geändert, so JVM diese Parameter angepasst wurde wenn das Programm läuft. Ich denke, ein oder zwei Tage später werden S0 und S1 wieder 512K sein. – vzyh

JVM genug Speicher, aber Frequenz voll gc

Antwort

Verwandte Themen