JVM отказывает под напряжением на RHEL 5.2
У меня есть (в настоящее время последний) jdk 1.6.0.18 катастрофических отказа при работе веб-приложения (в настоящее время последний) кот 6.0.24 неожиданно после 4 - 24 часов 4 часа к 8 дням стресс-тестирования (30 потоков, поражающих приложение на уровне 6 миллиметров. просмотры страниц/день). Это находится на RHEL 5.2 (Tikanga).
Отчет о катастрофическом отказе по http://pastebin.com/f639a6cf1, и последовательные части катастрофического отказа:
- SIGSEGV бросается
- на libjvm.so
- пространство рая всегда полно (100%)
JVM работает со следующими опциями:
CATALINA_OPTS="-server -Xms512m -Xmx1024m -Djava.awt.headless=true"
Я также тестировал память на аппаратные проблемы с помощью http://memtest.org/ в течение 48 часов (14 передач целой памяти) без любой ошибки.
Я включил -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps для осмотра для любых тенденций GC или исчерпания пространства, но там нет ничего подозрительного. GC и полный GC происходят в предикабельных интервалах, почти всегда освобождая те же мощности объема памяти.
Мое приложение, непосредственно, не использует собственного кода.
Какие-либо идеи того, где я должен посмотреть затем?
Редактирование - больше информации:
1) Нет никакого клиента vm в этом JDK:
[foo@localhost ~]$ java -version -server
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
[foo@localhost ~]$ java -version -client
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)
2) Изменение O/S не возможно.
3) Я не хочу заменять переменные стресс-теста JMeter, так как это могло скрыть проблему. Так как у меня есть вариант использования (текущий сценарий стресс-теста), который разрушает JVM, я хотел бы зафиксировать катастрофический отказ и не изменить тест.
4) Я сделал статический анализ своего приложения, но ничто серьезное не прибыло.
5) Память не растет со временем. Использование памяти уравновешивается очень быстро (после того, как запуск) в очень устойчивой тенденции, которая не кажется подозрительной.
6)/var/log/messages не содержит полезной информации прежде или во время катастрофического отказа
Подробнее: Забыл упоминать, что был апач (2.2.14) кот противостояния с помощью mod_jk 1.2.28. Прямо сейчас я запускаю тест без апача на всякий случай, катастрофический отказ JVM касается mod_jk собственного кода, который соединяется с JVM (коннектор кота).
После этого (если JVM отказывает снова) я попытаюсь удалить некоторые компоненты из своего приложения (кэширование, lucene, кварц) и позже попытаюсь использовать причал. Так как катастрофический отказ в настоящее время происходит в любое время между 4 часами к 8 дням, может потребоваться много времени для обнаружения то, что продолжается.
7 ответов
Есть ли у вас вывод компилятора? то есть PrintCompilation (и, если вы чувствуете себя особенно смелым, LogCompilation).
Я отлаживал подобный случай в этой части, наблюдая, что делает компилятор, и, в конце концов (это заняло много времени, пока не загорелась лампочка), я понял, что мой сбой был вызван компиляцией определенного метода в драйвер oracle jdbc.
В основном я бы сделал следующее:
- включил PrintCompilation
- , так как это не дает временных меток, напишу сценарий, который отслеживает этот файл журнала (например, засыпает каждую секунду и печатает новые строки) и сообщает, когда методы были скомпилированы (или нет)
- повторить тест
- проверить вывод компилятора, чтобы увидеть, соответствует ли сбой компиляции какого-либо метода
- повторить еще несколько раз, чтобы увидеть, есть ли шаблон
Если есть является заметным шаблоном, тогда используйте .hotspot_compiler (или .hotspotrc), чтобы он прекратил компилировать вызывающие ошибку методы, повторите тест и посмотрите, не взорвется ли он. Очевидно, в вашем случае, боюсь, теоретически этот процесс может занять месяцы.
некоторые ссылки
- для работы с выводом компиляции журнала -> http://wikis.sun.com/display/HotSpotInternals/LogCompilation+tool
- для информации о .hotspot_compiler -> http://futuretask.blogspot.com/2005/01/java-tip-7-use-hotspotcompiler-file-to.html или http://blogs.oracle.com / javawithjiva / entry / hotspotrc_and_hotspot_compiler
- действительно простой, быстрый и грязный сценарий для просмотра вывода компилятора -> http: // pastebin.com / Haqjdue9
- обратите внимание, что это было написано для solaris, у которого всегда есть причудливые опции для утилит по сравнению с эквивалентами GNU, так что, без сомнения, более простые способы сделать это на других платформах или с использованием других языков
Другое, что я бы сделал систематически изменять алгоритм gc, который вы используете и , проверять время сбоя по активности gc (например, коррелирует ли он с молодым или старым gc, как насчет TLAB?). Ваш дамп указывает на то, что вы используете параллельную очистку, поэтому попробуйте
- последовательный (молодой) сборщик (IIRC, он может быть объединен с параллельным старым)
- ParNew + CMS
- G1
, если он не повторяется с различными алгоритмами GC, тогда вы знаете, что дело в этом (и у вас нет исправления, кроме как изменить алгоритм GC и / или вернуться через старые JVM, пока вы не найдете версию этого алгоритма, которая не работает).
Несколько идей:
- Используйте другую версию JDK, Tomcat и / или ОС
- Немного измените параметры теста, например 25 потоков при 7,2 млн просмотров страниц в день
- Мониторинг или профилирование использования памяти
- Отладка или настройка сборщика мусора
- Выполнение статического и динамического анализа
Вы пробовали другое оборудование? Похоже, вы используете 64-битную архитектуру. По моему собственному опыту, 32-разрядная версия работает быстрее и стабильнее. Возможно, где-то тоже есть проблема с оборудованием. Время «от 4 до 24 часов» довольно распространено, чтобы быть просто проблемой программного обеспечения. Хотя вы говорите, что в системном журнале нет ошибок, я могу уйти. Тем не менее думаю, что стоит попробовать.
Попробуйте переключить контейнер сервлетов с Tomcat на Jetty http://jetty.codehaus.org/jetty/ .
Если бы я был на вашем месте, я бы сделал следующее:
- попробуйте немного более старые версии Tomcat/JVM. Похоже, что вы используете самую новую и лучшую. Я бы спустился на две версии вниз или около того, возможно, попробовал бы JRockit JVM.
- сделайте дамп потоков (kill -3 java_pid) во время работы приложения, чтобы увидеть полный стек. Ваш текущий дамп показывает много потоков, которые блокируются - но неясно, где они блокируются (ввод-вывод? внутренняя блокировка? что-то еще?). Я бы даже запланировал kill -3 на каждую минуту, чтобы сравнить любой случайный дамп потока с тем, который был непосредственно перед падением.
- Я видел случаи, когда Linux JDK просто умирает, в то время как Windows JDK способен изящно поймать исключение (тогда это было StackOverflowException), так что если вы можете изменить код, добавьте "catch Throwable" где-нибудь в верхнем классе. На всякий случай.
- Поиграйте с опциями настройки GC. Включите/выключите concurrent GC, настройте NewSize/MaxNewSize. И да, это не научная работа - скорее отчаянная потребность в рабочем решении. Более подробная информация здесь: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
Сообщите нам, как это было решено!
Можно ли вместо этого перейти на 32-битную JVM? Я считаю, что это наиболее зрелое предложение от Sun.
Увеличивается ли объем вашей памяти со временем? Если это так, я предлагаю снизить пределы памяти, чтобы увидеть, не дает ли система более частых сбоев при исчерпании памяти.
Сможете ли вы воспроизвести проблему быстрее, если:
- Вы уменьшите объем доступной для JVM памяти?
- Вы уменьшите доступные системные ресурсы (т. Е. Истощите системную память, так что JVM не хватит)
- Вы измените свой Преобразование вариантов использования в более простую модель?
Одна из основных стратегий, которые я использовал, - определить, какой вариант использования вызывает проблему. Это может быть общая проблема или конкретный вариант использования. Попробуйте зарегистрировать начало и остановку вариантов использования, чтобы узнать, сможете ли вы определить, какие варианты использования с большей вероятностью вызовут проблему. Если вы разделите свои варианты использования пополам, посмотрите, какая из них не работает быстрее всего. Это может быть более частой причиной сбоя. Естественно, выполнение нескольких испытаний каждой конфигурации повысит точность ваших измерений.
Известно, что я либо менял сервер, чтобы выполнять небольшую работу, либо зацикливался на работе, которую выполняет сервер. Один заставляет код вашего приложения работать намного сложнее, другой заставляет веб-сервер и сервер приложений работать намного тяжелее.
Удачи, Джейкоб