Warum ist mein Java-heap-dump-Größe viel kleiner als verwendeten Speicher?

Problem

Wir versuchen, den Schuldigen zu finden der ein großes memory leak in unserer web-Anwendung. Wir haben ziemlich wenig Erfahrung mit der Suche nach einem memory-leak, aber wir fanden heraus, wie man eine java-heap-dump mit jmap analysieren und es in Eclipse MAT.

Jedoch mit unserer Anwendung verwenden 56/60GB Speicher, der heap-dump ist nur 16 GB groß ist und noch weniger in Eclipse MAT.

Kontext

Verwendet unser server Wildfly 8.2.0 auf Ubuntu 14.04 für unsere java-Anwendung, deren Prozess verwendet 95% des verfügbaren Speichers. Wenn Sie den dump, unsere buffers/cache benutzt, der Raum war zu 56GB.

Nutzten wir den folgenden Befehl zum erstellen des dump: sudo -u {application user} jmap -dump:file=/mnt/heapdump/dump_prd.bin {pid}

Den heap-dump-Datei Größe ist 16,4 GB und bei der Analyse mit Eclipse MAT, es sagt, es gibt rund 1GB live-Objekte und ~14,8 GB nicht erreichbar/shallow heap.

EDIT: Hier ein paar mehr Infos über das problem, das wir sehen, passiert. Wir überwachen unsere Speicher-Auslastung, und wir sehen es wachsen und wachsen, bis es ~300mb freien Speicher. Dann bleibt es rund um diese Menge Speicher, bis der Prozess abstürzt, allerdings ohne Fehlermeldung in das Ereignisprotokoll der Anwendung.

Dies lässt uns annehmen, dass es eine harte OOM-Fehler, da dies nur passiert, wenn der Speicher ist fast aufgebraucht. Wir verwenden die Einstellungen -Xms25000m -Xmx40000m für unsere JVM.

Frage

Im Grunde genommen, Wundern wir uns, warum die Mehrheit unserer Speicher ist nicht gefangen in diesem Loch. Die top-beibehalten Größenklassen nicht allzu misstrauisch, so Wundern wir uns, wenn es etwas heap-dump-bezogene, was wir falsch machen.

  • Wie sind Sie mit der Messung der Speichernutzung der Anwendung? Nur weil der Java-Prozess verwendet X Arbeitsspeicher, bedeutet nicht, dass der Java-heap ist X.
  • Gut, wir sind mit dem linux-Befehl free -h um zu sehen, was unsere Speicherauslastung ist.
  • "bis der Prozess abstürzt, allerdings ohne Fehlermeldung im Anwendungsprotokoll" - schauen Sie sich das Verzeichnis mit der server-executables; das ist in der Regel das Verzeichnis, in dem die "java" - Befehl aufgerufen wird und das Verzeichnis, in dem die JVM erstellt eine crash-report-Datei. Sehen, wenn solche Dateien vorhanden sind, kann es einen Anhaltspunkt geben. Was Sie beschreiben, klingt wie eine harte virtuellen Maschine Abstürzen, nicht eine normale Java-Anwendung Ausnahme.
  • Sind Sie auf der Erfassung von stdout und stderr von der JVM? Wenn nicht, versuchen Sie diese Umleitung zu einer Datei und Sie sehen möglicherweise die Ausnahme.
  • Vielen Dank für die Anregungen Gimby & schtever, sehr geschätzt!
  • was ist die Ursache und der Grund, hast du das endlich herausfinden? Ich habe fast das gleiche problem.
  • du meinst, der cause & Grund der heap-dump-Größe? Oder die Ursache & Grund der OOM Fehler?
  • Ursache, warum der RES Speicher ist viel größer als die heap-Größe weggeworfen. Ich litt unter dem selben problem und Suche nach einer Antwort. Mein Programm sollte verbrauchen nur rund 3,9 g Speicher, da die dump-Größe 3,9 g aber die RES Größe ist viel größer, bis es erreicht der xms-Wert.
  • in meinem Fall, was geschah, war, dass mein Programm nicht genug Zeit, um eine vollständige garbage collection, so Speicher gehalten Gebäude. Wenn du die dump, es hatte genug Zeit, ein GC, das entlastet den Arbeitsspeicher, war der Aufbau. Das ist, warum ich sah den Unterschied zwischen heap-dump-Größe und Speicherbedarf. Ziemlich viel, was die akzeptierte Antwort sagt.
  • aber ich meinem Fall habe ich nicht einen anstrengenden Programm, und selbst nachdem ich-heap-dump, der RES ist immer noch die gleiche große. Ich Frage mich, ob die tatsächlichen RES wird immer größer, weil der Skala der jvm-heap ?

InformationsquelleAutor Thermometer | 2015-08-28
  1. 16

    Wenn dumping Ihre heap der JVM wird, führen Sie zuerst einen garbage-collection-Zyklus, um die Freiheit eines jeden nicht erreichbaren Objekte.

    Wie kann ich einen heap dump auf Java 5 ohne Müll sammeln erste?

    Meiner Erfahrung, in einem wahren Fehler wegen ungenügenden Speicherplatzes, auf dem die Anwendung ist einfach mehr heap-Speicher als verfügbar ist, dieser GC ist ein fool ' s errand und die endgültige heap dump wird die Größe der max. heap-Größe.

    Wenn der heap-dump ist viel kleiner, das heißt, das system war nicht wirklich aus der Erinnerung, aber vielleicht hatte der Arbeitsspeicher. Zum Beispiel gibt es die java.lang.OutOfMemoryError: GC overhead limit exceeded Fehler, was bedeutet, dass die JVM möglicherweise in der Lage, um frei genug Speicher zum Dienst einige neue Reservierungsanforderung, aber es musste zu viel Zeit auf das sammeln von Müll.

    Es ist auch möglich, dass Sie don ' T haben ein problem mit dem Arbeitsspeicher. Was macht Sie denken, Sie tun? Sie hat nicht erwähnt nichts über die heap-Verwendung oder einen OutOfMemoryError. Du hast nur erwähnt das JVM-Speicher-footprint auf dem Betriebssystem.

    • Sehr schöne Erklärung! ich habe aktualisiert die Frage mit den Antworten auf die Dinge, die Sie Fragen. Dies könnte der Grund sein, warum der heap-dump ist so viel niedriger in der Größe.
    InformationsquelleAutor Brandon
  2. 1

    Meiner Erfahrung, dass ein heap-dump, die viel kleiner als der Reale Speicher verwendet werden kann, durch ein Leck in der JNI.

    Obwohl Sie nicht direkt native-code, gibt es bestimmte Bibliotheken, die es verwenden, um zu beschleunigen.

    In unserem Fall war es eine Deflater und Inflater nicht ordnungsgemäß beendet.

    InformationsquelleAutor jcoll
Schreibe einen Kommentar