Enorme despejo de pilha (11 GB) - Jhat falhou & Eclipse TAPETE precisava de ajuda

Question

Temos um erro de memória no nosso EA e nós usado -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/some/dir para despejo de pilha no momento da OOM.

Tivemos um heap de memória de 12GB e perm gen de 256MB.

O heap dump é gerado na caixa de Linux onde temos o nosso aplicativo em execução e seu tamanho é de 11,5 GB.Não temos privilégios para fazer o download do nosso local.

Quando tentamos analisar o que 11 GB de informação de pilha usando JHAT é lançada uma OOM.

Tentamos os seguintes comandos a partir de nossa Linux CLI.

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

Para todas as opções de seu lançamento um OOM exceção depois de ler a informação de estado por vários minutos(>30 minutos).

Nós pesquisei e encontrei TAPETE como um poderoso despejo de pilha do analisador, mas não uma maneira de usá-lo no LINUX.

Qualquer sugestão seria de uma ajuda maior.Obrigado.

Modificado de:

Ficou brava instalado no Linux x86_64 máquina, mas tenho o seguinte erro quando executado ./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

Eu tentei ./ParseHeapDump.sh ../java_pid1491.hprof isso e tenho o seguinte erro,

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

Answer 1

Eu estava usando o TAPETE no Linux ontem....confira a versão correta aqui

Answer 2

esqueça Jhat, você precisaria de mais do que 100Gybte de RAM para analisar este despejo, ele levaria muito tempo e seria muito difícil encontrar algo.Eu só recentemente instalado TAPETE no SUSE 11 máquina.funcionou perfeitamente .Pode você por favor, certifique-se de que o TAPETE é usando o botão direito do JVM?Não tenho certeza se nós firewire-lo com qualquer outra coisa, em seguida, o SOL/SAP JVMs.

Cumprimentos, Markus (kohlerm)

Answer 3

Temos tido sucesso no passado, usando o Netbeans para analisar OOM erros.Parecia lidar onde o Eclipse e JHAT não podia.