Optimierung Von Tomcat / Garbage Collection
Unser server hat 128 GB RAM und 64 Kerne, läuft Tomcat 7.0.30-und Oracle jdk1.6.0_38, auf CentOS 6.3.
Alle 60 Minuten sehen wir die garbage collection, dass war 45 - 60 Sekunden. Durch das hinzufügen von-XX:-UseConcMarkSweepGC erhöhte Ladezeiten von über 10% bekam aber, dass bis zu etwa 3 Sekunden, das ist ein annehmbarer Kompromiss.
Unsere config:
-Xms30g -Xmx30g -XX:PermSize=8g -XX:MaxPermSize=8g -Xss256k -XX:-UseConcMarkSweepGC
Setzen wir die heap-auf 30 GB zu halten 32-bit-Adressierung (ich habe gelesen, dass über 32 GB, die 64-bit-Adressierung benötigt mehr Speicher, so haben Sie zu gehen bis zu 48 GB zu sehen, Verbesserungen).
Mit VisualGC ich kann sehen, dass die Eden Raum ist das Fahrradfahren durch alle 30 - 60 Minuten, aber nicht viel passiert mit den Überlebenden 0, Survivor 1, Alte Gen, und Perm Gen.
Haben wir einen leistungsstarken server. Welche anderen Optimierungen können wir mit einem weiteren Rückgang der 3-Sekunden-GC-Zeit?
Empfehlungen zur Verbesserung der performance oder Skalierung?
Alle anderen output oder config-info, die helfen würde?
-XX:-UseConcMarkSweepGC ist das nicht standardmäßig aus, vielleicht haben Sie gedacht, um es einzuschalten mit -XX:+UseConcMarkSweepGC Dies wird keinen Unterschied machen, die eden-Größe in jedem Fall.finden Sie, wo Sie erstellen Sie so viele Objekt-und sehen Sie, wo Sie optimieren mit pools und/oder caching
Wenn Sie sehen, dass wenig Aktivität auf der alten gen, warum sind Sie immer voller GCs. Ich vermute, es wird ausgelöst, wenn Sie es nicht brauchen.
Du hast Recht, das war ja auch nur ein + - Zeichen. Ich habe den Schalter, und die Ladezeiten um 50% erhöht. Ich habe nicht gesehen, wie lange GC dauert noch. Die anderen Verbesserungen aus unserer Schalter von OpenJDK auf Oracle JDK, und von 36GB heap zu 30GB heap.
Die HotSpot-Dokumentation ist etwas verwirrend, es sei denn, Sie Lesen das Kleingedruckte. Die Optionen, die nicht zeigen Ihnen wie Sie Optionen auf, die Sie Ihnen sagen, was die Standard-option ist. also, wenn Sie Sie verwenden, wie zitiert, die Sie nicht tun sollten alles. 😉
InformationsquelleAutor user1517922 | 2012-12-13
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ist es auch klingen mag counter-intuitive, aber Sie haben versucht, die Zuordnung eines viel weniger Speicher? E. g. brauchen Sie wirklich eine 30G-heap? In Fall können Sie zusammen mit 4G oder sogar noch weniger: Garbage collection könnte häufiger sein, aber wenn es passiert, wird es viel schneller sein. Normalerweise finde ich dies mehr als wünschenswert Zuordnung einer Menge von Speicher, leiden die Zeit, die es braucht, um es zu säubern.
Selbst wenn diese Ihnen nicht helfen, weil Sie wirklich brauchen, 30G Speicher, andere wiederum kommen mit einem ähnlichen problem, und Sie profitieren möglicherweise von der Zuteilung weniger.
Im Falle der -Xmx ist realistisch, ich mag zu empfehlen -Xmx identisch sein -Xms: Wenn Sie beginnen mit 2G, aber der VM entscheidet, Sonntag Nacht um 3 Uhr, dass er will, reservieren seine volle Zulage vom OS aber fehlschlägt, erhalten Sie eine OOM trotz richtig die maximale. Zumindest für die Produktion-Systeme ist dies meine Standard-Empfehlung. Für nicht-würde ich dir Zustimmen.
Die Verhaltensweisen die du beschreibst für Produktionssysteme erfordert zudem fügen Sie -XX:+AlwaysPreTouch, sonst faulen die Absonderung von Ihrem Betriebssystem, können Sie dennoch zu einer überraschung, wenn die JVM versucht zuerst die Verwendung mit einem bestimmten Abschnitt des heap.
Danke, @pauldoo. Ich werde auf jeden Fall einen Blick und fügen Sie diese in der toolbox.
InformationsquelleAutor Olaf Kock
Scheint, dass Sie brauchen, Inkrementelle GC zu reduzieren Pausen:
und für die Rückverfolgung ohne visualgc das ging immer gut für mich (Ausgang in catalina.out):
Nachdem Sie mit spielen können:
Referenz: Virtual Machine Garbage Collection Tuning
InformationsquelleAutor ggrandes