Riesiger Heap-Dump (11 GB) - Jhat fehlgeschlagen & Eclipse MAT brauchte Hilfe

Question

Wir haben einen Speicherfehler in unserem EA und wir haben verwendet -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/some/dir um den Haufen zum Zeitpunkt von OOM zu entleeren.

Wir hatten einen Heap-Speicher von 12 GB und eine Dauerwelle von 256 MB.

Der Heap-Dump wird in der Linux-Box generiert, in der unsere Anwendung ausgeführt wird, und seine Größe beträgt 11,5 GB.Wir haben keine Privilegien, es auf unser lokales herunterzuladen.

Als wir versuchten, diesen 11-GB-Heap-Dump mit zu analysieren JHAT es warf ein OOM.

Wir haben die folgenden Befehle von unserer Linux-CLI ausprobiert.

jhat java_pid1491.hprof
jhat -J-Xmx16g -XX:-UseBiasedLocking java_pid1491.hprof
jhat -J-d64 -J-Xmx16g -J-XX:-UseBiasedLocking java_pid1491.hprof#1

Für alle Optionen wird nach dem Lesen des Speicherauszugs für einige Minuten (> 30 Minuten) eine OOM-Ausnahme ausgelöst.

Wir haben es gegoogelt und gefunden MATTE als leistungsstarker Heap-Dump-Analysator, aber keine Möglichkeit, ihn unter LINUX zu verwenden.

Irgendwelche Vorschläge wären eine größere Hilfe.Danke.

Mutierend:

Habe MAT auf einem Linux x86_64-Computer installiert, habe aber bei der Ausführung den folgenden Fehler erhalten ./MemoryAnalyzer

(.:17319): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(.:17319): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
(.:17319): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed
(.:17319): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed
(.:17319): Gtk-WARNING **: Screen for GtkWindow not set; you must always set
a screen for a GtkWindow before using the window
(.:17319): Gdk-CRITICAL **: gdk_pango_context_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed
(.:17319): Pango-CRITICAL **: pango_context_set_font_description: assertion `context != NULL' failed
(.:17319): Pango-CRITICAL **: pango_context_set_base_dir: assertion `context != NULL' failed
(.:17319): Pango-CRITICAL **: pango_context_set_language: assertion `context != NULL' failed
(.:17319): Pango-CRITICAL **: pango_layout_new: assertion `context != NULL' failed
(.:17319): Pango-CRITICAL **: pango_layout_set_text: assertion `layout != NULL' failed
(.:17319): Pango-CRITICAL **: pango_layout_set_attributes: assertion `layout != NULL' failed
(.:17319): Pango-CRITICAL **: pango_layout_set_alignment: assertion `layout != NULL' failed
(.:17319): Pango-CRITICAL **: pango_layout_set_ellipsize: assertion `PANGO_IS_LAYOUT (layout)' failed
(.:17319): Pango-CRITICAL **: pango_layout_set_single_paragraph_mode: assertion `PANGO_IS_LAYOUT (layout)' failed
(.:17319): Pango-CRITICAL **: pango_layout_set_width: assertion `layout != NULL' failed
(.:17319): Pango-CRITICAL **: pango_layout_get_extents: assertion `layout != NULL' failed
(.:17319): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed
(.:17319): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed
(.:17319): Gtk-CRITICAL **: gtk_icon_size_lookup_for_settings: assertion `GTK_IS_SETTINGS (settings)' failed
(.:17319): Gtk-WARNING **: Invalid icon size 6
(.:17319): Gtk-CRITICAL **: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed
Segmentation fault

Ich habe es versucht ./ParseHeapDump.sh ../java_pid1491.hprof dies und bekam folgenden Fehler,

Caused by: java.lang.NoClassDefFoundError: com/ibm/dtfj/image/CorruptDataException
        at org.eclipse.mat.dtfj.InitDTFJ.stop(InitDTFJ.java:70)

Answer 1

Ich habe gestern MAT unter Linux benutzt....überprüfen Sie die richtige Version hier

Answer 2

vergiss das, du würdest mehr als 100 GB RAM brauchen, um diesen Dump zu analysieren, es würde ewig dauern und es wäre sehr schwer, etwas zu finden.Ich habe MAT erst kürzlich auf einem SUSE 11-Computer installiert.funktionierte einwandfrei .Können Sie bitte sicherstellen, dass MAT die richtige JVM verwendet?Ich bin mir nicht sicher, ob wir es mit etwas anderem als den SUN / SAP-JVMs getestet haben.

Bezug, Markus (kohlerm)

Answer 3

Wir hatten in der Vergangenheit Erfolg damit, Netbeans zur Analyse von OOM-Fehlern zu verwenden.Es schien damit fertig zu werden, wo Eclipse und JHAT es nicht konnten.