1. Zuhause
  2. Frage und Antwort
  3. Speicherzuordnung Verhalten mit Java 1.8 in Tomcat 6 und Tomcat 8

Speicherzuordnung Verhalten mit Java 1.8 in Tomcat 6 und Tomcat 8

2015-09-04 8 views
14

Verwandte Frage: Garbage collector usage when upgrade from Java 6 + Tomcat 6 to Java 8 + Tomcat 8Speicherzuordnung Verhalten mit Java 1.8 in Tomcat 6 und Tomcat 8

ich eine Reihe von Webapps haben, kompiliert mit Java 8. Wenn ich sie in Tomcat laufen 8, erhalte ich eine Menge kleinere GC Sammlungen mit einer zufälligen Speicherzuordnung. In Tomcat 6 ist die Speicherzuweisung linearer und stabiler (Leerlauf in beiden Fällen, kein Verkehr).

Eden Raum Tomcat 8:

enter image description here

enter image description here

Eden Raum Tomcat 6:

enter image description here

enter image description here

Wissen Sie, warum das passiert?

EDIT 1:

Dies sind die Daten aus der Produktionsumgebung mit jdk 1.8 und Tomcat 8. CPU fast wirklich hoch ist immer auf GC-Zyklen. Irgendwelche Kommentare dazu?

enter image description here enter image description here

EDIT 2:

Dies ist ein heapdump analisis (1,8 GB Dump):

enter image description here

Quelle

2015-09-04 Fran Montero

+0

Mit mehr GC-Anrufe verwenden Sie weniger CPU. –

+1

@GilianJoosen jeder GC-Zyklus erfordert CPU (siehe CPU-Image), ein Speicherleck könnte eine kontinuierliche Speicherbereinigung mit einer 100% CPU-Zeit und einem unbrauchbaren Server führen. –

+1

Mit 2 Hauptversionen zwischen Tomcat 6 und Tomcat 8 wäre die Antwort etwas wie "weil sie Dinge verändert haben". Was passiert, wenn Sie Verkehr haben und Tomcat nicht nur im Leerlauf sitzt (da ist es wirklich wichtig). Geht dir der Speicher aus? Verschlechtert sich Ihre Leistung mit Tomcat 8? – Kayaman

Antwort

2

Dieser Raum eden, nicht die fest angestellten Raum. Also, das allein ist eine gute Nachricht.

Aber dieser Schritt der Erinnerung scheint tomcat8 zu sein, das nach einem jungen GC sofort etwas zuweist. Könnte es eine Ballon-Technik sein? (Zuweisung eines großen schwach referenzierten Puffers zur schnellen Deflation, um bei Speicherdruck Platz zu schaffen). Es kann sich auch in NIO-Konnektoren verstecken, wie im 'oomParachute' -Parameter (1 MB standardmäßig, aber ist es pro httpprocessor-Thread? Wenn Sie 200 min-Threads hätten, würde das 200 MB entsprechen).

Ich schlage nur vor, dass Sie in das Changelog bohren können, um neue Dinge oder Änderungen zu finden, von denen Sie denken, dass sie verschwenderisch wie ein solcher Balloon-Mechanismus implementiert wurden.

AUCH: Sie sollten den tomcat6 in Ihrem jdk8 laufen lassen, um zu sehen, ob es wirklich tomcat8 an der Schuld ist. Der Eden-Raum könnte größer gemacht werden, nur für den Fall, dass der G1GC so aggressiv ist, dass er sich verpflichtet fühlt, GC zu verwenden, wenn nur 200 MB verwendet werden.

Quelle

2016-02-07 14:13:54 user2023577

+0

Danke für Ihre Antwort. Wie ich in der Post gesagt habe, ich die gleichen Anwendungen auf Tomcat 6 und Tomcat 8 ausführen. Das "Extrange" Verhalten tritt nur mit Tomcat 8 auf. Ich habe das Problem mit Javosize gefunden, schaue auf meine Antwort. –

1

Vielen Dank alle Jungs für Ihre Zeit. Am Ende ist das Problem ein Fehler in Tomcat 8.0_23. Javosize Verwendung, i ein Thread sah fast alle CPU zeitraubend: Ich fand diese Tomcat AJP Bug

In adittion

enter image description here

im Internet sucht, ich habe tomcat getestet 8.0_32 und das Poller Thread tut nicht einmal existiert so Problem gelöst.

Mit freundlichen Grüßen

Quelle

2016-02-19 11:47:43

Verwandte Themen

 Verwandte Themen