Что посмотреть дальше в файле журнала hs_err_pid ###.? - PullRequest
Новая
       26

Что посмотреть дальше в файле журнала hs_err_pid ###.?

0 голосов
/ 08 февраля 2019

Если я вижу что-то вроде следующего в файле журнала hs_err_pid ###., Это хороший признак утечки или просто закончилась память?

Ниже приведена история кучи GC.Есть 250 событий, и все они выглядят одинаково с использованием пространства eden при 100% использовании, и ParOldGen также максимально используется.

GC Heap History (250 events):
Event: 603738.947 GC heap before
{Heap before GC invocations=10735 (full 1042):
 PSYoungGen      total 245248K, used 220160K [0x00000000d5580000, 0x00000000e8680000, 0x0000000100000000)
  eden space 220160K, 100% used [0x00000000d5580000,0x00000000e2c80000,0x00000000e2c80000)
  from space 25088K, 0% used [0x00000000e2c80000,0x00000000e2c80000,0x00000000e4500000)
  to   space 26112K, 0% used [0x00000000e6d00000,0x00000000e6d00000,0x00000000e8680000)
 ParOldGen       total 1398272K, used 1398162K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
  object space 1398272K, 99% used [0x0000000080000000,0x00000000d5564b30,0x00000000d5580000)
 Metaspace       used 78830K, capacity 83683K, committed 146496K, reserved 1132544K
  class space    used 8021K, capacity 11589K, committed 62824K, reserved 1048576K

Может ли следующее быть связано с вышеизложенным?GC Failed из-за недостатка места? 

Events (250 events):
Event: 603741.921 Executing VM operation: ParallelGCFailedAllocation
Event: 603742.654 Executing VM operation: ParallelGCFailedAllocation done
Event: 603742.655 Executing VM operation: ParallelGCFailedAllocation

Похоже ли, что стек из файла указывает на то, что происходит сбой в слое JNI из-за ссылки на файл libjvm.so? 

Stack: [0x00002b19adbe2000,0x00002b19adce2000],  sp=0x00002b19adce0970,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x687782]
V  [libjvm.so+0x61061d]
V  [libjvm.so+0x474bb6]
V  [libjvm.so+0x612aff]
V  [libjvm.so+0xad56b7]
V  [libjvm.so+0xad3fc8]
V  [libjvm.so+0xad4499]
V  [libjvm.so+0xad48f1]
V  [libjvm.so+0x8beb82]

Вот siginfo, но она мне мало что говорит: 

 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000040

Исходя из вышесказанного, это приводит к утечке или ошибке памяти?Каким будет следующий фрагмент файла журнала для исследования для дальнейшей диагностики этой проблемы?

1 Ответ

0 голосов
/ 08 февраля 2019

Является ли это хорошим признаком утечки или просто закончилась память

Нет.Если память закончится, JVM выдаст OutOfMemoryError.Неважно (куча или родная).В случае, если jvm не может выделить собственную память, необходимую через malloc или mmap, возвращая NULL, это будет пониматься как JVM и выдает OOME либо.

SEGV означает, что процесс пытался получить доступ к неверному расположению памяти(например, 0 или местоположение не принадлежит процессу).

Без отладочных символов JVM трудно сказать что-то конкретное.

...