Java разбился приложение - как узнать, почему Java упал? - PullRequest
Новая
       30

Java разбился приложение - как узнать, почему Java упал?

2 голосов
/ 15 февраля 2011

Мой java-сервер неоднократно начинал аварийно завершать работу, и я не могу найти причину.

У меня есть сервер с 7,5 ГБ памяти и я выделил 3 ГБ для процесса Java.

Сервер былработает нормально, и запускал сборку мусора много раз, но JVM зависал при нагрузке на память.

Вот информация из JConsole, после сбоя: 

Current heap size: 
2 958 868 kbytes
Maximum heap size: 
3 066 816 kbytes
Committed memory: 
3 066 816 kbytes
Pending finalization: 
0 objects
Garbage collector: 
Name = 'PS MarkSweep', Collections = 66, Total time spent = 7 minutes
Garbage collector: 
Name = 'PS Scavenge', Collections = 43 055, Total time spent = 44 minutes



Operating System: 
Linux 2.6.31-302-ec2
Architecture: 
amd64
Number of processors: 
2
Committed virtual memory: 
8 405 760 kbytes
Total physical memory: 
7 882 780 kbytes
Free physical memory: 
   34 540 kbytes
Total swap space: 
        0 kbytes
Free swap space: 
        0 kbytes

У меня 0,5 ГБ послеGC запускается, поэтому все время он увеличивается с 0,5 до 3 ГБ, а затем падает до 0,5, это абсолютно не проблема с подвешенными объектами.На самом деле он должен бросить OutOfMemoryException вместо сбоя.Я использую эти параметры: 

-Xmn256m -Xms768m -Xmx3000m -XX:NewRatio=2 -server -verbosegc -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:+UseParallelGC -XX:ParallelGCThreads=2 -XX:+UseParallelOldGC

Что не так и что мне делать?Показанный результат был: 

Current thread (0x00007fe899755800):  JavaThread "508616253@qtp-1871151428-3352" [_thread_in_vm, id=11941, stack(0x00007fe86a4e5000,0x00007fe86a5e6000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000

Registers:
RAX=0x00007fe9c60333b8, RBX=0x00007fe899755800, RCX=0x0d00007fe8f58787, RDX=0x00007fe9c6031888
RSP=0x00007fe86a5e3fd0, RBP=0x00007fe86a5e4020, RSI=0x00007fe899755800, RDI=0x00007fe95bae1770
R8 =0x00007fe9be341620, R9 =0x0000000000000001, R10=0x00007fe9c5b84460, R11=0x00007fe9c051a52b
R12=0x00007fe9c051a529, R13=0x00007fe9c6034ac0, R14=0x00007fe9c051a599, R15=0x0900007fe8f58787
RIP=0x00007fe9c5bd562d, EFL=0x0000000000010246, CSGSFS=0x000000000000e033, ERR=0x0000000000000000
  TRAPNO=0x000000000000000d

Stack: [0x00007fe86a4e5000,0x00007fe86a5e6000],  sp=0x00007fe86a5e3fd0,  free space=3fb0000000000000030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x64d62d]
V  [libjvm.so+0x5fc4df]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::_complete_monitor_locking_Java
J  sun.nio.ch.SocketChannelImpl.write(Ljava/nio/ByteBuffer;)I
J  org.mortbay.io.nio.ChannelEndPoint.flush(Lorg/mortbay/io/Buffer;)I
J  org.mortbay.jetty.HttpGenerator.flush()J
...

Ответы [ 4 ]

1 голос
/ 15 февраля 2011

Из аварийного документа, который вы связали, ошибка - SIGSEGV, которая является ошибкой чтения / записи в собственную память.Стек потока показывает его сбой в коде JVM. 

Current thread (0x00007fe899755800):  JavaThread "508616253@qtp-1871151428-3352" [_thread_in_vm, id=11941, stack(0x00007fe86a4e5000,0x00007fe86a5e6000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000

Registers:
RAX=0x00007fe9c60333b8, RBX=0x00007fe899755800, RCX=0x0d00007fe8f58787, RDX=0x00007fe9c6031888
RSP=0x00007fe86a5e3fd0, RBP=0x00007fe86a5e4020, RSI=0x00007fe899755800, RDI=0x00007fe95bae1770
R8 =0x00007fe9be341620, R9 =0x0000000000000001, R10=0x00007fe9c5b84460, R11=0x00007fe9c051a52b
R12=0x00007fe9c051a529, R13=0x00007fe9c6034ac0, R14=0x00007fe9c051a599, R15=0x0900007fe8f58787
RIP=0x00007fe9c5bd562d, EFL=0x0000000000010246, CSGSFS=0x000000000000e033, ERR=0x0000000000000000
  TRAPNO=0x000000000000000d

Stack: [0x00007fe86a4e5000,0x00007fe86a5e6000],  sp=0x00007fe86a5e3fd0,  free space=3fb0000000000000030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x64d62d]
V  [libjvm.so+0x5fc4df]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::_complete_monitor_locking_Java
J  sun.nio.ch.SocketChannelImpl.write(Ljava/nio/ByteBuffer;)I
J  org.mortbay.io.nio.ChannelEndPoint.flush(Lorg/mortbay/io/Buffer;)I
J  org.mortbay.jetty.HttpGenerator.flush()J
<snip>

Возможно, это ошибка JVM или, возможно, повреждение памяти.

0 голосов
/ 15 февраля 2011

Если у вас «проблема с памятью» означает, что вы беспокоитесь о том, что ваше физическое оборудование неисправно, вам следует серьезно рассмотреть возможность его стресс-тестирования.

Для традиционных ПК это можно сделать с помощью memtest86. Последняя версия доступна здесь: http://www.memtest.org/

Если память проходит ночной тест с memtest86, вы можете быть уверены, что он работает правильно.

0 голосов
/ 15 февраля 2011

Когда вы говорите, что вы выделили 3 ГБ для JVM, был ли это размер кучи или общий размер (который может быть немного больше), например JVM с кучей 3 ГБ может использовать всего 4 ГБ.

Если JVM потерпел крах на GC, я бы проверил, есть ли у вас текущая версия JVM, например Java 6 update 23.

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

0 голосов
/ 15 февраля 2011

Звучит как утечка памяти.Gc может очищать только те объекты, на которые больше нет ссылок.И если ваше приложение (или сам сервер) не «освобождает» неиспользуемые ресурсы, через некоторое время даже 3 ГБ недостаточно.

Профилировщик может помочь идентифицировать структуры данных, которые неожиданно растут.

Идея: запустите сервер с параметром -verbose:gc и проверьте, что происходит перед тем, как он умрет.Уменьшите пространство кучи для теста, чтобы вам не пришлось долго ждать.Если это утечка памяти, я ожидаю, что вы увидите обычный полный цикл gc, когда gc может освобождать меньше памяти при каждом запуске.

Обновление

Я былвводить в заблуждение тегом outofmemoryerror.Фактически это сбой JVM, и все, что вы можете сделать, это попытаться обновить установленную Java.Уже есть некоторые сообщения о сбоях "SIGSEGV (0xb)" для сборок 1.6.0_17 и 1.6.0_18 ( как этот вопрос на SO ).

Это внутренняя проблема JVM.

...