Когда дело доходит до высокой загрузки процессора, я обычно смотрю на две вещи:
- Частое GC потребляя CPU
- Темы потребляющих CPU
Для диагностики # 1 далее, что позволяет GC Logging может быть лучшим способом. Тем не менее, вы можете использовать jstat, а также:
jstat -gc PID 60s
выше команда будет собирать использования памяти и сборки мусора детали из виртуальной машины Java каждые 60-е годы. В среде отладки 60-е годы должны быть в порядке, но в производственной среде должно быть достаточно 3600. jstat - очень легкий вес, не создает никаких неблагоприятных последствий. Результат поможет вам понять, есть ли частые GC (майор/минор). Частая крупная коллекция - проблема наверняка (она приостанавливает приложение), однако очень частая небольшая коллекция может также вызвать высокий процессор (приложение слишком часто создает слишком много мусора). Если это так, возможно, вам нужен главный дамп, и вам нужно понять детали использования памяти приложения, но не раньше этого. Помните, что захват дампа кучи может «повесить» ваше приложение (я не предлагаю его на производстве, если вы не можете перезапустить приложение сразу после захвата данных).
Для диагностики № 2 «верх» предоставляет опцию («Н») для проверки процессора, потребляемого отдельными потоками. Это будет указывать (в реальном времени) потоки приложений, которые потребляют процессор. Также (как предложили другие), захватите 5/6 потоки резьбы с интервалом в 10 секунд каждый. Ищет потоки в состоянии RUNNABLE. Это потоки, которые выполняют работу и, следовательно, занимают центральный процессор. Является ли тот же (набор) поток застрял в состоянии Runnable по нескольким дампам? Вероятно, у вас есть проблема.
Надеюсь, это поможет. Удачи!
