JVM часто дает сбой

JVM неожиданно и часто дает сбой в нашей рабочей среде, что приводит к падению Jboss (EAP6.3). У нас установлена ​​java7 U72

Журналы сбоев имеют тот же вывод, что и текущий поток:

Текущий поток (0x00000000d1d99000): демон JavaThread «Lucene Merge Thread #0» [_thread_in_Java, id = 1144, stack (0x00000000f6a00000,0x00000000f6b00000)]

и весь журнал заполнен:

Демон JavaThread «elasticsearch [Node BD852E44] [search] [T # 68]» [_thread_blocked, id = 14396, stack (0x00000000f7b30000,0x00000000f7c30000)]

elasticsearch некоторые из них были связаны с индексированием, и насколько я понимаю, он использует Lucene в капюшоне, но у нас есть номер или развернутое приложение, как это проверить, может кто-нибудь помочь. полные журналы сбоев находятся по адресу: http://pastebin.com/845LU9iK.


jvm jboss lucene jvm-hotspot
person Rahul Pathak    schedule 20.02.2015    source источник
comment
Не могли бы вы вставить полный крашлог? Сбои уже трудно диагностировать, если вы удалите контекст, это станет еще сложнее.   -  person the8472    schedule 20.02.2015
comment
Это не позволит мне пройти полные журналы здесь .. вы можете предложить, как это сделать?   -  person Rahul Pathak    schedule 20.02.2015
comment
pastebin или gist.github   -  person the8472    schedule 20.02.2015
comment
pastebin.com/845LU9iK ... вот полные журналы   -  person Rahul Pathak    schedule 20.02.2015
comment
Убедитесь, что вы не используете сборщик мусора G1. Дополнительные сведения см. на странице wiki.apache.org/lucene-java/JavaBugs.   -  person mindas    schedule 20.02.2015
comment
спасибо @mindas - я администратор, не знаю, как проверить, работает ли GC1, или нет, не могли бы вы сообщить мне, как это проверить? ... Я не уверен, слышали ли вы о программном обеспечении Appian BPM, которое размещается в приложении Jboss сервер, когда мы связались со службой поддержки Appian, также упомянули что-то, связанное с GC, так что это то, что мне интересно проверить ...   -  person Rahul Pathak    schedule 20.02.2015
comment
@mindas Согласно аварийному дампу, используется CMS GC, а не G1.   -  person apangin    schedule 21.02.2015
comment
Так что с коллектором все в порядке или что-то надо проверить и для CMS GC.   -  person Rahul Pathak    schedule 21.02.2015

Ответы (1)


arrow_upward
0
arrow_downward

Похоже, ему не удалось записать трассировку стека для затронутого потока. Если это одинаково для всех сбоев, то, похоже, это не соответствует известным ошибкам lucene или jboss.

#  guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter

AIUI это указывает на ошибку в собственной обработке исключений, поэтому одна ошибка маскирует другую, что, вероятно, делает этот журнал сбоев довольно бесполезным.

Поэтому я могу дать только действительно общий совет:

  • вы используете более старую версию JVM, обновитесь до последней версии java 7, java 8 или, возможно, даже до сборки разработчика java 9 и посмотрите, исчезнет ли она.
    Даже если они все еще вылетают, они могут предоставлять другие/более полезные отчеты об ошибках.
  • to diagnose potential compiler bugs you can try running with the following flags
    • -XX:-TieredCompilation 1 should disable the C1 compiler
    • -XX:+TieredCompilation -XX:TieredStopAtLevel=1 должен отключить компилятор C2
    • -Xint отключает все JIT, очень медленно
  • запросите дальнейшие указания в списке рассылки hotspot-dev.

1: Многоуровневая компиляция — это новая функция java 7, она в основном объединяет интерпретатор, JIT-компиляторы C1 и C2 (которые ранее использовались отдельно в клиентских и серверных виртуальных машинах) на разных этапах оптимизации.

В каждом из них могут быть ошибки оптимизации. Отключение отдельных этапов помогает изолировать их как потенциальную причину.

Редактировать: новый отчет о сбоях более полезен, поскольку в нем есть как минимум фреймы Java, интересная часть заключается в следующем:

J 1559  sun.misc.Unsafe.getByte(J)B (0 bytes) @ 0x000000000178e99b [0x000000000178e960+0x3b]
j  java.nio.DirectByteBuffer.get()B+11
j  org.apache.lucene.store.ByteBufferIndexInput.readByte()B+4
J 9447 C2 org.apache.lucene.store.DataInput.readVInt()I (114 bytes) @ 0x000000000348cc00 [0x000000000348cbc0+0x40]

DataInput.readVInt кажется постоянным источником горя, см. этот ответ SO для возможных решений

person the8472    schedule 20.02.2015
comment
Недавно мы повысили java до jdk1.7.0_72 из jdk1.6.0_26... проблема все еще не устранена, не уверен, что продвижение java на следующий уровень было бы полезно... Есть ли способ узнать собственный код, который запускает applicatino Люсен...? Кроме того, я не уверен, как и что произойдет, если я отключил флаг компилятора ... поэтому запуск вслепую в среде Prod - это то, что может серьезно ухудшить ситуацию ... есть ли ссылка, на которую я могу ссылаться, чтобы получить более подробную информацию о флагах, которые вы поставляется? - person Rahul Pathak; 20.02.2015
comment
Если вы не хотите делать это в рабочей среде, я рекомендую настроить среду, которая копирует производственную среду, и воспроизвести проблему там. Это или жить с падением производительности во время тестирования, я предполагаю, что сбои JVM ничем не лучше, чем медленные JVM. Я добавлю некоторые подробности относительно параметров. - person the8472; 21.02.2015
comment
Есть ли способ узнать собственный код, из которого applicatino запускает Lucene. Не уверен, что вы спрашиваете. - person the8472; 21.02.2015
comment
Что касается этого момента, мы не уверены, что является триггером для возникновения сценария проблемы или как вызвать проблему ... поэтому много думали, но не пришли. У нас есть несколько приложений, развернутых на Prod, и мы не уверены, какое приложение использует Lucene ... поэтому я спросил que ... «есть ли способ узнать собственный код, из которого applicatino запускает Lucene» ... если мы сможем найти это мы отключим или удалим функциональность, пока это не будет исправлено... - person Rahul Pathak; 21.02.2015
comment
Запрос на отключение компилятора и устранение неполадок не был одобрен. Вместо этого мы разделили JVM и добавили еще один экземпляр JBoss, чтобы заботиться о поисковом сервере, который использует elasticsearch (Lucene). Теперь у нас есть два экземпляра jvm, один для основного каталога уха, а другой для поискового сервера. и снова произошел сбой (на удивление главный ухо jvm разбился, а поисковый сервер был запущен и работал) в этот понедельник журналы сбоев могут находиться по адресу: pastebin. com/wWWG9edh может кто-нибудь просмотреть - person Rahul Pathak; 06.03.2015
comment
Я не уверен, была ли это ошибка или что-то еще ... мы продолжали переходить от более новой и более новой версии и, наконец, Java версии 7, обновление 78, мы больше не сталкиваемся с проблемой сбоя JVM. спасибо всем за вашу помощь на данный момент проблема решена - person Rahul Pathak; 27.03.2015