отладка JBoss 100% загрузка процессора

Question

Первоначально опубликовано при сбое сервера , где предполагалось, что этот вопрос лучше задать здесь.

Мы используем JBoss для запуска двух наших WAR. Одним из них является наше веб-приложение, другим является наш веб-сервис. Веб-приложение обращается к базе данных на другом компьютере и делает запросы к веб-службе. Веб-служба отправляет запросы JMS на другие машины, объединяет данные и возвращает их.

У нашего крупнейшего клиента примерно один раз в месяц процесс JBoss Java занимает 100% всех процессоров. Машина под управлением JBoss имеет 8 процессоров. В это время наше веб-приложение все еще доступно, однако загрузка страниц занимает около 3 минут. Перезапуск JBoss восстанавливает все до нормального состояния.

С машиной базы данных и всеми остальными машинами все в порядке, затрагивается только машина, на которой работает JBoss. Использование памяти нормальное. Использование сети нормальное. В журналах JBoss нет подозрительных сообщений об ошибках.

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

Куда мы пойдем отсюда? Как мы можем сузить проблему?

В настоящее время единственный план, который у нас есть, - это дождаться, пока проблема возникнет самостоятельно, а затем выполнить некоторую отладку, чтобы определить причину. До сих пор люди только что перезапустили JBoss, когда возникла проблема, чтобы минимизировать время простоя. В следующий раз, когда это случится, они заставят разработчика взглянуть. Вопрос в следующем, что может быть сделано для определения причины?

Мы могли бы установить отдельный экземпляр JBoss в той же коробке и установить веб-приложение отдельно от веб-службы. Таким образом, когда возникнет следующая проблема, мы узнаем, в какой WAR возникла проблема (при условии, что это наш код). Это не сильно сужает это все же.

Должен ли я включить JMX remote? Таким образом, в следующий раз, когда возникнет проблема, я могу подключиться к VisualVM и посмотреть, какие потоки загружают процессор и какого черта они делают. Однако есть ли существенный недостаток при включении JMX remote в производственной среде?

Есть ли другой способ узнать, какие потоки потребляют ресурсы процессора, и получить трассировку стека, чтобы увидеть, что они делают?

Есть еще идеи?

Спасибо!

Answer 1

Существует быстрый и грязный способ определения того, какие потоки используют процессорное время на JBoss. Перейдите на консоль JMX с браузером (обычно на http://localhost:8080/jmx-console,, но может отличаться для вас), найдите bean-компонент с именем ServerInfo, в нем есть операция с именем listThreadCpuUtilization, которая выводит фактическое время ЦП, используемое каждый активный поток, в хорошем табличном формате. Если есть одно неправильное поведение, оно обычно выделяется как больной большой палец.

Существует также операция listThreadDump, которая выгружает стек для каждого потока в браузер.

Не так хорошо, как профилировщик, но гораздо более простой способ получить основную информацию. Для производственных серверов, где часто бывает плохо подключать профилировщик, это очень удобно.

Answer 2

Как правило, это происходит с использованием кода быстрого запуска или небезопасного доступа потоков к хэш-картам. Простой дамп потока (kill -3, как говорит @disown, или ctrl-break в консоли Windows) покажет эту проблему.

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

Обычно я стараюсь сделать стандартную рабочую процедуру для выполнения дампов потоков из любой JVM, которая перезапускается из-за эксплуатационных аномалий, и действительно требуется ловить эти данные раз в месяц.

Answer 3

Если вы используете JBoss 5.1.0 EAP, в Jboss есть ошибка, и они также имеют исправление. Вот URL: https://issues.jboss.org/browse/JBPAPP-5193

Answer 4

Я думаю, вам определенно следует попытаться настроить тестовую среду с некоторым нагрузочным тестированием, чтобы воспроизвести вашу проблему. Профилирование определенно помогло бы точно определить проблему.

Быстрое исправление - в следующий раз убить jboss с помощью kill -3, чтобы получить дамп для анализа. Второе, что я хотел бы проверить, это то, что вы используете флаги -server и ваши настройки gc нормальны. Вы также можете просто запустить dstat, чтобы увидеть, что делает процесс во время блокировки. Но опять же - вероятно, безопаснее просто установить среду нагрузочного тестирования (через EC2 или около того), чтобы воспроизвести это.