Garbage Collector lässt Programm kurz hängen

[leon_20v]

Hallo,

in einem Thread werden Daten erstellt, die dann Serialisiert werden. Ich habe bei der Synchronisation keinen Verklemmungen und keine wartezeiten (mit JProfiler getestet).

Denn wird der Erzeugerthread immer für 50ms unterbochen. Hab viel gegoogelt und geschaut und bin dann darauf gekommen der GC könnte Schuld sein wenn ich nach der Serialisierung die Objekte aufräume. Immer wenn ich Lücken von meinem Erzeuger habe räumt der GC auf: [Times: user=0.05 sys=0.00, real=0.04 secs]

Kann ich das iwi einstellen? Damit der das Aufräumen unterbricht damit mein Programm weiter arbeiten kann?


Vielen Dank für eure Hilfe. Hab schon GC tuning gegoogelt aber iwi steht da nicht das was ich suche.

 

[turtle]

Damit der das aufräumen unterbricht

Nein, das geht natürlich NICHT. :noe:

Denn das würde die Stabilität des Java-Systems gravierend beeinflussen und daher geht DAS grundsätzlich nicht. Beispiel. JVM möchte GC machen, weil Speicher knapp wird, du unterbrichst den GC und legst im Programm noch 1,23456 Objekte an also knallt die ganze JVM.😱

Was aber geht, ist, den Garbage Collector mit Parametern zu "steuern". Dies ist aber definitiv nicht ganz einfach und erfordert grösseres Wissen über die verschiedenen GC-Algorithmen und deren Arbeitsweise (insbesondere Performance-Optionen) Hier findest du eine erste Anlaufstelle.

 

[leon_20v]

Ich hab das schon probiert, aber iwi kann er dann die JVM nicht mehr starten:

java -Xmx512m -Xms512m -Xmn1g
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX😛arallelGCThreads=20
-XX:SurvivorRatio=8
-XX:TargetSurvivorRatio=90
-XX:MaxTenuringThreshold=31

 

[turtle]

ich sagte ja😉

Dies ist aber definitiv nicht ganz einfach

Ich würde Schritt für Schritt gehen und nicht mehrere Parameter auf einmal ändern. Danach kannst du das Programm mit dem neuen Paramtersatz testen und wenn du meinst, es läuft besser, weitere Schritte machen.

 

[leon_20v]

leider nimmt er keiner dieser parameter an ;(

 

[nvidia]

leider nimmt er keiner dieser parameter an ;(

Ja, vll. sollte man einfach über die verwendete Kombination nachdenken. Eine Übersicht zu den Hotspot-Paramentern findet sich hier Java HotSpot VM Options

 

[leon_20v]

vll hab ich über die kombination nachgedacht und diese sollte so ok sein, aber die jvm will einfach ned...

 

[turtle]

java -Xmx512m -version

Nimmt er bei mir beispielsweise an und liefert

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

 

[leon_20v]

was mich so wundert, warum der gc den alle threads kurz blocked. das ist doch einfach doof dass da nix passiert 50ms... Naja ist halt kein Echtzeitsystem aber trotzdem, sowas nervt doch einfach...


Wenn das nicht Funktioniert den GC einzustellen so dass der vernünftig läuft, dann kann ich nur noch die Objekte recyclen, d.h. wenn ich Serialisiere die Objekte zum Deserialisieren nehmen und umgekehrt. Dann muss der GC nicht mehr soviel aufräumen...

Würde glaub in meinem Fall funktoinieren, da ich Daten auf die Platte schreibe und lese die ganze Zeit.

 

[turtle]

was mich so wundert, warum der gc den alle threads kurz blocked

Das nennt man bei der Garbage Collection STOP-THE-WORLD und lässt sich nicht vermeiden egal welchen GC-Algorithmus du nimmst.

Du kannst "lediglich" dafür sorgen, das du weniger Aufrufe und/oder kürzere Zeiten einer GC erhältst. Aber grundsätzlich bleiben ALLE Threads (für kurze Zeit) stehen, daher der Name stop-the-world.

Es ist ein ziemlicher Aufwand hier einen guten Kompromiss zwischen Performance und Durchsatz zu erhalten.

 

[leon_20v]

Naja, ich bekomms ned auf die Reihe, ich werde wohl die Objecte recyclen ^^