JVM überschreitet die maximale Speicher definiert mit -Xmx

Haben wir eine Java-webapp, dass wir ein Upgrade von Java 1.5.0.19 Java 1.6.0.21

/usr/java/jdk1.6.0_21/bin/java -server -Xms2000m -Xmx3000m -XX:MaxPermSize=256m -Djava.awt.headless=true -Dwg.environment=production -Djava.io.tmpdir=/var/cache/jetty -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=31377 -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/webapp -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/3p/jboss/lib/endorsed -classpath /opt/3p/jboss/bin/run.jar:/usr/java/jdk1.6.0_21/lib/tools.jar org.jboss.Main -c default

Wie Sie sehen können, es sollte preallocate 2 GB heap und max bei 3GB (warum wir preallocate so viel ist, weil diese app ist uralt und schlecht entwickelt, so hat eine Tonne von Dingen zu laden). Das Problem, das wir gesehen haben vor kurzem, nach dem Upgrade auf die 1.6 ist das ab und an mal den Speicher durch die Decke geht. Während die Speicherauslastung ist wahrscheinlich ein app-Problem ist die JVM eine überschreitung der 3GB max setup für heap. Mit top sehe ich:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND    
8449 apache    18   0 19.6g 6.9g 5648 S  4.0 84.8  80:42.27 java

Also, wie könnte eine JVM mit 3GB heap, 256 MB permgen, und sogar einige overhead verbrauchen 6,9 GB? Bug in der JVM, die würden behoben werden, indem die Aktualisierung auf build #35? Vermissen Sie etwas auf, was in java könnte mit den zusätzlichen Speicher? Nur versuchen, um zu sehen, ob jemand das schon mal gesehen.

Native code-Bibliotheken unterliegen nicht entweder auf dem heap oder permgen Grenzen (für Speicher mit malloc, sagen). Verwenden Sie keine signifikante nativen Bibliotheken?
Die OS-distribution verwenden Sie?
NÖ. Wir verwenden eine Reihe von Java-libs, aber kein native libs.
was ist die tatsächliche java-heap-Größe, wenn der Speicher schießt nach oben?
Da bist du auf Linix, verwenden Sie pmap, um herauszufinden, wo der Speicher eigentlich vor sich geht.

InformationsquelleAutor Benny the Guard | 2012-09-06

  1. 12

    Also, wie könnte eine JVM mit 3GB heap, 256 MB permgen, und sogar einige overhead verbrauchen 6,9 GB?

    Mögliche Erklärungen sind:

    • Unmengen von thread-stacks,
    • memory-mapped-Dateien, die nicht geschlossen wird, wenn Sie sein sollten,
    • einige native-code-Bibliothek, die mit (eventuell undicht) out-of-heap-Speicher.

    Ich würde geneigt sein, die Schuld der Anwendung, bevor die Schuld der JVM.

    +1 für "die Schuld der Anwendung, bevor die Schuld der JVM"
    Das war meine Neigung als gut, aber ich habe nie gesehen, dass ein Java-Prozess verbraucht zu viel. Wir sind nicht über eine native Bibliotheken, also nicht sicher, ob das könnte ein Problem sein. Nicht memory-mapped-Dateien zählen vor Herzinfarkten? Die thread-stacks werde ich versuchen zu untersuchen und zu sehen, wie viele es sind.
    "nicht memory-mapped-Dateien zählen gegen Haufen?" Sie nicht. Das mapped-memory-Segmenten zugeordnet sind, die außerhalb des Java-Heaps.
    OK. Sieht aus wie thread-stacks wird gesteuert über -Xss-was wir nicht explizit festlegen. Doc sagt, das sollte 1MB sein. Irre ich mich oder bedeutet das, dass wir ausschließen können dies als eine mögliche Problem? Wir haben JMX konfiguriert, so werde ich versuchen und sehen, ob das hilft überhaupt.
    Sie können nur die Regel-thread-stacks aus, wenn Sie wissen, dass Sie nicht über eine große Anzahl von threads. (Und laichen eine große Anzahl von threads ist etwas, das einem alten, schlecht gestaltete webapp könnte zu tun. ~4000 x 1Mb ~4Gb ...)

    InformationsquelleAutor Stephen C

  2. 9

    Also lange Geschichte kurz, meine erste Reaktion war richtig, es war ein bug in der JVM. Wir waren mit 1.6.0_21 und es stellt sich heraus, dass wir da gerade genau denselben Fehler wie in https://confluence.atlassian.com/pages/viewpage.action?pageId=219023686. Upgrade auf 1.6.0_37 das problem behoben und wir gingen aus dem täglichen Abstürze zu 2 Wochen ohne einen Absturz.

    Während also das Gefühl, nicht nur die Schuld der JVM ist eine gute Politik, es scheint, dass sollte man auch ratsam, nicht immer annehmen, dass die JVM ist bug-frei, wie alle software, hat die gelegentliche Fehler. Plus, scheint eine gute Strategie, um Dinge auf dem Laufenden halten.

    Dank für all die Hilfe auf dieser!

    InformationsquelleAutor Benny the Guard

  3. 2

    http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html

    Beachten Sie, dass die JVM verwendet mehr Speicher als nur den heap. Zum Beispiel
    Java-Methoden, die thread-stacks und native Griffe zugeordnet sind, im Speicher
    getrennt von den Haufen, als auch die JVM-internen Datenstrukturen.

    Also, wenn Sie haben eine Menge threads und eine Menge einheimischer behandelt, die Speicher können über den heap begrenzen. Sind Sie sicher, dass dies nicht vor?

    Überprüfen Sie auch diese: Java mit mehr Speicher als den zugewiesenen Speicher

    Es geschah nicht vor dem 1.6 aktualisieren. Es gab jedoch auch andere Probleme und andere app wechselt als gut. Also ich vermute, es ist in der Tat-und app-Fehler-und wir werden versuchen und Blick auf die heap-dump, die wir gerade erhalten haben. Während ich verstehe, könnte es einige zusätzliche overhead -, > 3 GB der Aufwand scheint übertrieben. Könnte threads, die Kopflosen, etc wirklich so viel?
    Dies hängt von den threads und vor allem deren Aufruflisten. Wenn Sie verwenden eine Menge von Rekursion in eine Menge von threads, dies könnte sehr gut bis zu sehr viel Speicher (die nicht beseitigt werden können, die von der GC)

    InformationsquelleAutor Peter Ilfrich

Schreibe einen Kommentar