отладка JBoss 100% использование ЦП
Первоначально отправленный на Отказе сервера, где этому предложили, этот вопрос мог бы лучше спрошенный здесь.
Мы используем JBoss для выполнения двух из наших ВОЙН. Каждый - наше веб-приложение, другой наш веб-сервис. Веб-приложение получает доступ к базе данных по другой машине и выполняет запросы к веб-сервису. Веб-сервис выполняет запросы JMS к другим машинам, агрегировал данные и возвращает их.
В нашем крупнейшем клиенте, об один раз в месяц процессе Java JBoss берет 100% всех центральных процессоров. Машина, выполняющая JBoss, имеет 8 центральных процессоров. Наше веб-приложение все еще доступно в это время, однако страницы занимают приблизительно 3 минуты для загрузки. Перезапуск JBoss восстанавливает все к нормальному.
Машина баз данных и все другие машины прекрасны, только машина, выполняющая JBoss, затронута. Использование памяти нормально. Использование сети нормально. В журналах JBoss нет никаких подозрительных сообщений об ошибках.
Я настроил тестовую среду максимально близко к продуктивной среде клиента, и я сделал тестирование загрузки с так же как 2x число параллельных пользователей. Я не заставил свою тестовую среду копировать проблему.
Куда мы идем отсюда? Как мы можем сузить проблему?
В настоящее время единственный план, который мы имеем, состоит в том, чтобы ожидать, пока проблема не происходит в производстве самостоятельно, затем сделайте некоторую отладку для определения причины. До сих пор люди только что перезапустили JBoss, когда проблема произошла для уменьшения времени простоя. В следующий раз, когда это происходит, они заставят разработчика смотреть. Вопрос, в следующий раз, когда это происходит, что может быть сделано для определения причины?
Мы могли установить отдельный экземпляр JBoss на том же поле и установить веб-приложение отдельно от веб-сервиса. Таким образом, когда проблема затем происходит, мы будем знать, какая ВОЙНА имеет проблему (предполагающий, что это - наш код). Это не сужает его очень все же.
Я должен включить JMX удаленный? Таким образом, в следующий раз, когда проблема происходит, я могу соединиться с VisualVM и видеть, какие потоки берут ЦП и что, черт возьми, они делают. Однако есть ли значительное вниз сторона к включению JMX, удаленного в продуктивной среде?
Там другой путь состоит в том, чтобы видеть, какие потоки едят ЦП и заставить stacktrace видеть то, что они делают?
Какие-либо другие идеи?
Спасибо!
3 ответа
Я думаю, вам обязательно стоит попробовать настроить тестовую среду с некоторым нагрузочным тестированием, чтобы воспроизвести вашу проблему. Профилирование определенно поможет выявить проблему.
Быстрое решение - в следующий раз убить jboss с помощью kill -3, чтобы получить дамп для анализа. Второе, что я хотел бы проверить, это то, что вы работаете с флагами -server и что ваши настройки gc в порядке. Вы также можете просто запустить некоторый dstat, чтобы увидеть, что делает процесс во время блокировки. Но опять же - вероятно, безопаснее просто настроить среду нагрузочного тестирования (через EC2 или около того), чтобы воспроизвести это.
Существует быстрый и грязный способ определения того, какие потоки используют время ЦП на JBoss. Откройте консоль JMX с помощью браузера (обычно на http: // localhost: 8080 / jmx-console , но может быть другим для вас), найдите bean-компонент с именем ServerInfo , у него есть операция под названием listThreadCpuUtilization , которая выводит фактическое время ЦП, используемое каждым активным потоком, в красивом табличном формате. Если что-то плохо себя ведет, оно обычно выделяется, как больной большой палец.
Также существует операция listThreadDump , которая выгружает стек для каждого потока в браузер.
Не так хорош, как профилировщик, но гораздо более простой способ получить основную информацию. Для производственных серверов, где подключение профилировщика часто является плохой новостью, это очень удобно.
Обычно это происходит с неконтролируемым кодом или небезопасным доступом потока к хэш-картам. Простой дамп потока (kill -3, как говорит @disown, или ctrl-break в консоли Windows) выявит эту проблему.
Поскольку вы не можете воспроизвести это с помощью тестов, я думаю, что это пахнет проблемой параллелизма; Обычно трудно заставить тестовые сценарии вести себя достаточно случайным образом, чтобы выявить проблемы этого типа.
Обычно я стараюсь сделать его стандартной рабочей процедурой для создания дампов потоков любой JVM, которая перезапускается из-за операционных аномалий, и это действительно требование, чтобы отловить эти раз в месяц вещи.