Идеи онлайн-устранения неполадок приложений Java, сводка инструментов

❝

Оригинальный адрес:Java приложение Онлайн устранение неполадок Сводка

Оригинал не простой, укажите источник.

❞

предисловие

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

Просто напоминание здесь. Есть только одна главная цель, о которой нужно помнить во время чрезвычайной ситуации в Интернете:"Восстановите службу как можно скорее, чтобы устранить последствия". Независимо от того, на каком этапе чрезвычайной ситуации мы должны сначала подумать о проблеме восстановления.Проблема восстановления может быть не в состоянии определить местонахождение проблемы, и не может быть идеального решения.О ней можно судить по опыту, или это может быть предустановленным переключатель и т. д., но это может заставить нас достичь цели быстрого восстановления, а затем зарезервировать часть сайта, а затем определить проблему, решить проблему и возобновить восстановление.

Хорошо, теперь давайте перейдем к делу.

1. Высокая загрузка ЦП/рост

❝

Примечание. Использование ЦП — важный показатель для измерения загруженности системы. но"Безопасный порог для использования ЦП является относительным и зависит от того, является ли ваша система Io-интенсивной или вычисляющей". Как правило, приложения с интенсивными вычислениями имеют высокую загрузку ЦП и низкую нагрузку, а приложения с интенсивным вводом-выводом — наоборот.

❞

"Общие причины:"

• частый gc
• Бесконечный цикл, блокировка потока, ожидание ввода-вывода... и т.д.

моделирование

Здесь для демонстрации используйте простейший бесконечный цикл для имитации сцены парения процессора, ниже приведен код моделирования,

Добавьте один из самых простых веб-проектов SpringBoot.CpuReaperэтот класс,

/**
 * 模拟 cpu 飙升场景
 * @author Richard_yyf
 */
@Component
public class CpuReaper {

    @PostConstruct
    public void cpuReaper() {
        int num = 0;
        long start = System.currentTimeMillis() / 1000;
        while (true) {
            num = num + 1;
            if (num == Integer.MAX_VALUE) {
                System.out.println("reset");
                num = 0;
            }
            if ((System.currentTimeMillis() / 1000) - start > 1000) {
                return;
            }
        }
    }
}

После упаковки в jar запустите его на сервере.java -jar cpu-reaper.jar &

Шаг 1. Найдите проблемную ветку

Метод A: Традиционный метод

1. topПозиционирование самого высокопроизводительного процесса ЦП

   воплощать в жизньtopКоманда для просмотра рейтинга всех процессов, занимающих системный ЦП, и определения того, какой процесс является призраком. В данном случае это наш Java-процесс. Столбец PID — это идентификатор процесса. (См. [Приложение], если значение индикатора неясно.)

   

2. top -Hp pidНайдите поток с максимальной загрузкой ЦП

   

3. printf '0x%x' tidИдентификатор потока преобразован в шестнадцатеричный

   > printf '0x%x' 12817
   > 0x3211

4. jstack pid | grep tidнайти стек потоков

   > jstack 12816 | grep 0x3211 -A 30

Метод Б:show-busy-java-threads

Сценарий поступает из проекта с открытым исходным кодом на проекте GitHub предоставляет множество полезных сценариев,show-busy-java-threadsявляется одним из них. С помощью этого скрипта утомительные шаги метода А можно упростить напрямую. следующее,

> wget --no-check-certificate https://raw.github.com/oldratlee/useful-scripts/release-2.x/bin/show-busy-java-threads
> chmod +x show-busy-java-threads

> ./show-busy-java-threads

show-busy-java-threads
# 从所有运行的Java进程中找出最消耗CPU的线程（缺省5个），打印出其线程栈

# 缺省会自动从所有的Java进程中找出最消耗CPU的线程，这样用更方便
# 当然你可以手动指定要分析的Java进程Id，以保证只会显示你关心的那个Java进程的信息
show-busy-java-threads -p <指定的Java进程Id>

show-busy-java-threads -c <要显示的线程栈数>

Метод c: Артасthread

Али с открытым исходным кодомarthasТеперь он почти взял на себя нашу онлайн-работу по устранению неполадок, предоставляя очень полный набор инструментов. В этом сценарии только одинthread -nкоманда сделает.

> curl -O https://arthas.gitee.io/arthas-boot.jar # 下载

❝

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

Подробности смотрите на официальном сайте: https://alibaba.github.io/arthas/thread.html

❞

следовать за

После прохождения первого шага, после выявления проблемного кода, после наблюдения за стеком потоков. мы"Необходимо анализировать конкретные проблемы". Вот несколько примеров.

Случай 1: обнаружено, что наибольшая загрузка ЦП приходится на поток GC.

GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fd99001f800 nid=0x779 runnable
GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fd990021800 nid=0x77a runnable 
GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fd990023000 nid=0x77b runnable 
GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fd990025000 nid=0x77c runnabl

gc должен проверить много контента, поэтому я решил перечислить его в отдельном разделе позже.

Случай 2: обнаружено, что наибольшая загрузка ЦП приходится на бизнес-поток.

• io wait
  • Напримерэтот пример, io заблокирован из-за недостатка места на диске из-за
• В ожидании состояния ядра, такого как синхронизированные
  • jstack -l pid | grep BLOCKEDПросмотр стека заблокированных потоков
  • Сделайте дамп стека потоков, чтобы проанализировать состояние блокировки потока.
  • Артас обеспечиваетthread -b, вы можете узнать, какие потоки в настоящее время блокируют другие потоки. Для синхронного случая

2. Частый ГК

1. Просмотрите процесс GC

Прежде чем понять следующее содержание, пожалуйста, найдите время, чтобы просмотреть весь процесс GC.

---

Продолжая предыдущее содержание, в данном случае мы, естественно, хотим проверить конкретную ситуацию gc.

• Способ а: просмотр журнала сборщика мусора
• Метод б:jstat -gcutil 进程号 统计间隔毫秒 统计次数（缺省代表一致统计
• Способ c: Удобнее, если в вашей компании есть компоненты, контролирующие работу приложения (типа Prometheus + Grafana)

Вот дополнительное объяснение включения gc log. Часто обсуждаемый вопрос (инерционное мышление) заключается в том, следует ли включать ведение журнала сборки мусора в производственных средах. Поскольку накладные расходы, которые он создает, обычно очень ограничены, мой ответ таков:"включи". Но не обязательно указывать параметры журнала GC при запуске JVM.

❝

HotSpot JVM имеет специальный класс параметров, называемых управляемыми параметрами. Для этих параметров их значения могут быть изменены во время выполнения. Все параметры, которые мы здесь обсуждаем, и те, которые начинаются с «PrintGC», являются управляемыми параметрами. Таким образом, мы можем включить или отключить ведение журнала GC в любое время. Например, мы можем использовать инструмент jinfo, который поставляется с JDK, для установки этих параметров или вызвать его через клиент JMX.HotSpotDiagnostic MXBean的setVMOption для установки этих параметров.

И снова артас❤️, он обеспечиваетvmoptionКоманды могут напрямую просматривать и обновлять параметры, связанные с диагностикой ВМ.

❞

После получения журнала gc вы можете загрузить его наGC easyПомогите анализу, получите визуальные результаты анализа диаграммы.

2. Причины и позиционирование GC

"prommotion failed"

Объекты в зоне раскрутки от S лет тоже нельзя отпускать вызывают FullGC (fgc recovery неверный бросок OOM).

возможная причина:

• "Область выжившего слишком мала, и объекты преждевременно вступают в старость."

  Просмотр параметра SurvivorRatio

• "Распределение больших объектов, недостаточно памяти"

  дамп кучи, профайлер/MAT анализирует занятость объекта

• "В старом районе много объектов"

  дамп кучи, профайлер/MAT анализирует занятость объекта

Вы также можете сделать вывод о проблеме из-за эффекта полного GC.В нормальных условиях полный GC должен вернуть много памяти, поэтому"Кривая памяти нормальной кучи должна быть формой пиломатериалов". Если вы обнаружите, что память кучи едва уменьшилась после полной сборки мусора, вы можете сделать вывод:"В куче находится большое количество невосстанавливаемых объектов, и они постоянно расширяются, так что коэффициент использования кучи превышает порог срабатывания полного GC, но их невозможно восстановить, что приводит к непрерывному выполнению полного GC."Другими словами, это может быть"утечка памяти".

В общем, вывод исключений, связанных с сборщиком мусора, должен включать"анализ памяти",использоватьjmapтакие инструменты, как выгрузка моментальных снимков памяти (илиheapdump), а затем использовать инструменты визуального анализа памяти, такие как MAT, JProfiler, JVisualVM и т. д.

Что касается шагов после анализа памяти, вам необходимо проанализировать конкретные проблемы в соответствии с конкретными проблемами.

3. Исключение пула потоков

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

Часто задаваемые вопросы и причины

Этот тип пула резьбы ненормальный, и, как правило, имеет следующие причины:

1. "Время отклика нисходящей службы (RT) слишком велико"

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

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

2. "База данных медленный sql или тупик базы данных"

Просмотр ключевых слов журнала

3. "Взаимоблокировки кода Java"

   jstack –l pid | grep -i –E 'BLOCKED | deadlock'

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

В-четвертых, общая проблема восстановления

❝

На эту часть содержания ссылаетсяэта статья

❞

5. Артас

Здесь я все же хочу использовать инструмент Arthas в отдельном разделе.

ArthasЭто инструмент диагностики Java с открытым исходным кодом от Alibaba, основанный на методе Java Agent и использующий метод Instrumentation для изменения метода байт-кода для диагностики приложений Java.

• Приборная панель: панель данных системы в реальном времени, может проверять поток, память, сборщик мусора и другую информацию.

• thread : просмотр информации о текущем потоке, просмотр стека потоков, например, просмотр самых загруженных верхних n потоков.

• getstatic: получить значения статических свойств, напримерgetstatic className attrNameМожет использоваться для просмотра фактического значения онлайн-переключателя

• sc: просмотр информации о загруженном классе jvm, которую можно использовать для устранения неполадок, связанных с конфликтами пакетов jar.

• sm: просмотр информации о методе загруженных классов jvm

• jad: декомпилировать информацию о классе загрузки jvm и проверить причину, по которой логика кода не выполняется

• Регистратор: Просмотр информации о регистратеру, обновить уровень регистратора регистрации

• смотреть: наблюдать за данными выполнения метода, включая выходные параметры, входные параметры, исключения и т. д.

• трассировка: продолжительность внутреннего вызова метода и вывод времени, затрачиваемого каждым узлом для анализа производительности.

• tt: используется для записи метода и воспроизведения

❝

Вышеизложенное взято изОфициальная документация Артаса.

❞

Кроме того,Arthasтакже интегрированognlЭтот легкий механизм выражений, через ognl, вы можете использовать arthas для выполнения множества «дерзких» операций.

Об остальном здесь много говорить не буду, если вам интересно, вы можете перейти в официальную документацию по артасу и github issue.

6. Используемые инструменты

Поговорим о некоторых инструментах.

• Arthas(Супер рекомендуется ❤️❤️)
• useful-scripts
• GC easy
• Smart Java thread dump analyzer - thread dump analysis in seconds
• PerfMa — анализ параметров виртуальной машины Java/дампа потока/дампа памяти
• Команды Linux
• Java N Axe
• Инструменты анализа визуальной памяти, такие как MAT, JProfiler...

Эпилог

Я знаю, что моя статья не является исчерпывающим обзором сетевых аномалий, и"Сеть (тайм-ауты, переполнение очереди TCP...)", память вне кучи и многие другие аномальные сценарии не задействованы. Главным образом потому, что у меня очень мало контактов, и у меня не было глубокого понимания и исследования.Заставлять его писать это неизбежно сделает его почти подлым, и я больше боюсь совершить ошибку.

Что я также хочу сказать, так это то, что онлайн-проверка Java-приложений на самом деле очень сложна в отношении того, есть ли у человека прочная основа и прошла ли проверка способность решать проблемы. Например, механизм работы пула потоков, анализ gc, анализ памяти Java и т. д., если основа не прочная, чтение будет более запутанным. Кроме того, просмотрите несколько хороших статей в Интернете об устранении неполадок с исключениями, чтобы, даже если вы не столкнетесь с ними временно, вы постепенно суммировали набор структурных схем для решения подобных проблем в своем уме, а затем вы действительно столкнулись с ними. , Это просто вопрос аналогии.

❝

Если эта статья была вам полезна, я надеюсь, что вы можете поставить лайк, это самая большая мотивация для меня 🤝🤝🤗🤗.

❞

Ссылаться на

• https://developer.aliyun.com/article/757655
• Документация Артас 3.2.0
• «Архитектура распределенных сервисов: принципы, проектирование и практика»

приложение

Значение индикаторов, отображаемых верхней командой

показатель	значение
PID	идентификатор процесса
USER	владелец процесса
PR	Приоритет процесса
NI	хорошее значение. Отрицательные значения указывают на высокий приоритет, положительные значения указывают на низкий приоритет
VIRT	Общий объем виртуальной памяти, используемой процессом, в КБ. ВИРТ=ОБМЕН+РЕЗ
RES	Размер физической памяти, используемой процессом, но не выгружаемой, в КБ. RES=КОД+ДАННЫЕ
SHR	Объем разделяемой памяти, кб
S	Статус процесса. D=непрерываемое состояние сна R=работа S=сон T=отслеживание/остановка Z=процесс зомби
%CPU	Процент времени ЦП, использованного с момента последнего обновления
%MEM	Процент физической памяти, используемой процессом
TIME+	Общее время ЦП, используемое процессом, в 1/100 секунды
COMMAND	Имя процесса (имя команды/командная строка)