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

Question

Первоначально опубликовано on Server Fault, где было предложено задать вопрос здесь.

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

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

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

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

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

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

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

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

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

Любые другие идеи?

Спасибо!

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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