Опыт онлайн-устранения неполадок и решения проблем ЦП 100% и приложения OOM

Java
Опыт онлайн-устранения неполадок и решения проблем ЦП 100% и приложения OOM

⛽zipkin2.reporter.InMemoryReporterMetrics приводит к устранению и устранению неполадок с ЦП сервера 100% и проблем с OOM приложения.

Ниже приведены проблемы, с которыми я столкнулся, и некоторые простые идеи по устранению неполадок.Если что-то не так, пожалуйста, оставьте сообщение для обсуждения. Если вы столкнулись с проблемой OOM, вызванной InMemoryReporterMetrics, и решили ее, вы можете проигнорировать эту статью. Если вы не понимаете, как CPU100% и OOM устраняют неполадки в сети, вы можете просмотреть эту статью.

проблемное явление

【Уведомление о тревоге - ненормальная тревога приложения】

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

Описание окружающей среды

Версия Spring Cloud F.


Проект использует зависимость spring-cloud-sleuth-zipkin для получения zipkin-reporter по умолчанию. Проанализированная версия обнаружила, что версия zipkin-reporter — 2.7.3.

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
		
版本： 2.0.0.RELEASE

在这里插入图片描述

Устранение неполадок

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

1. Проверьте состояние службы и убедитесь, что URL-адрес проверки работоспособности в порядке.

Этот шаг можно пропустить/пропустить, он связан с реальной проверкой работоспособности компании и не является универсальным.

① Проверьте, существует ли процесс службы.

ps -ef | имя службы grep ps -aux | имя службы grep

② Проверьте, нормальный ли адрес соответствующей проверки работоспособности службы, и проверьте, правильный ли IP-порт.

Неправильно указан адрес службы аварийной сигнализации? Как правило, это не вызовет проблем


③Подтвердите адрес проверки работоспособности

Этот адрес для проверки работоспособности выглядит следующим образом:http://192.168.1.110:20606/serviceCheckПроверьте правильность IP и порта.

# 服务正常返回结果
curl http://192.168.1.110:20606/serviceCheck
{"appName":"test-app","status":"UP"}

# 服务异常，服务挂掉
curl http://192.168.1.110:20606/serviceCheck
curl: (7) couldn't connect to host

2. Просмотрите журнал службы

Проверьте, печатаются ли еще журналы службы и поступают ли запросы. Ознакомьтесь также с Discovery Service OOM.

在这里插入图片描述

подсказки:

Превышен лимит накладных расходов java.lang.OutOfMemoryError GC Официальный представитель Oracle дал причину и решение этой ошибки: Исключение в потоке thread_name: java.lang.OutOfMemoryError: превышен лимит накладных расходов GC Причина: Подробное сообщение «Превышено предельное количество служебных данных GC» указывает на то, что сборщик мусора работает все время и программа Java работает очень медленно.После сборки мусора, если процесс Java тратит на сборка мусора, и если она восстанавливает менее 2% кучи и до сих пор выполняла последние 5 (постоянная времени компиляции) последовательных сборок мусора, то выдается ошибка java.lang.OutOfMemoryError. Это исключение обычно возникает из-за того, что количество оперативных данных едва помещается в кучу Java, имея мало свободного места для новых распределений. Действие: увеличьте размер кучи Исключение java.lang.OutOfMemoryError для превышения лимита накладных расходов сборщика мусора можно отключить с помощью флага командной строки -XX:-UseGCOverheadLimit.

причина: Это, вероятно, означает, что JVM тратит 98% времени на сборку мусора и получает только 2% доступной памяти.Частая переработка памяти (выполнено не менее 5 последовательных сборок мусора), JVM выставит ava.lang.OutOfMemoryError : Ошибка превышения лимита служебных данных GC.

在这里插入图片描述

Источник приведенных выше советов:java.lang.OutOfMemoryError Превышен лимит накладных расходов сборщика мусора Причина Анализ и решения

3. Проверьте использование ресурсов сервера

Чтобы запросить статус занятости ресурсов каждого процесса в системе, используйте команду top. Достаточно увидеть, что есть процесс с номером 11441, у которого загрузка ЦП достигает 300%, как показано на следующем снимке экрана:

在这里插入图片描述


Затем запросите использование ЦП всеми потоками в рамках этого процесса:

топ -H -p pid Сохраните файл: top -H -n 1 -p pid > /tmp/pid_top.txt

# top -H -p 11441
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
11447 test    20   0 4776m 1.6g  13m R 92.4 20.3  74:54.19 java
11444 test    20   0 4776m 1.6g  13m R 91.8 20.3  74:52.53 java
11445 test    20   0 4776m 1.6g  13m R 91.8 20.3  74:50.14 java
11446 test    20   0 4776m 1.6g  13m R 91.4 20.3  74:53.97 java
....

Глядя на потоки ниже PID: 11441, обнаруживается, что несколько потоков занимают большую часть ЦП.

4. Сохраните данные стека


1. Распечатайте снимок загрузки системы
top -b -n 2 > /tmp/top.txt
top -H -n 1 -p pid > /tmp/pid_top.txt


2. Процессор выводит список потоков, соответствующих процессу, в порядке возрастания.
ps -mp -o THREAD,tid,time | sort -k2r > /tmp/process_threads.txt


3. Посмотрите на количество tcp-соединений (лучше всего несколько раз)
lsof -p идентификатор процесса > /tmp/идентификатор процесса_lsof.txt
lsof -p идентификатор процесса > /tmp/идентификатор процесса_lsof2.txt


4. Просмотрите информацию о цепочке (лучше всего сделать выборку несколько раз)
jstack -l идентификатор процесса > /tmp/идентификатор процесса_jstack.txt
jstack -l идентификатор процесса > /tmp/идентификатор процесса_jstack2.txt
jstack -l идентификатор процесса > /tmp/идентификатор процесса_jstack3.txt


5. Просмотрите обзор использования памяти кучи
jmap -идентификатор процесса кучи> /tmp/идентификатор процесса_jmap_heap.txt


6. Просмотр статистики объектов в куче
jmap -histo идентификатор процесса | head -n 100 > /tmp/идентификатор процесса_jmap_histo.txt


7. Просмотр статистики сборщика мусора
jstat -gcutil идентификатор процесса > /tmp/идентификатор процесса_jstat_gc.txt

8. Создание моментального снимка кучи Дамп кучи
jmap -dump:format=b,file=/tmp/ID процесса_jmap_dump.hprof ID процесса

Всех данных куча, сгенерированный файл больше.

jmap -dump:live,format=b,file=/tmp/process ID_live_jmap_dump.hprof ID процесса

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

Получите данные моментального снимка и перезапустите службу.

анализ проблемы


В соответствии с вышеуказанными операциями были получены такие данные, как информация GC, стеки потоков и моментальные снимки кучи рассматриваемой службы. Следующий анализ проводится, чтобы увидеть, в чем заключается проблема.

1. Проанализируйте потоки, которые занимают 100% ЦП

Преобразование идентификатора потока

Анализ процесса стека потоков, сгенерированный из jstack.

Установите идентификатор потока выше как
11447: 0x2cb7
11444: 0x2cb4
11445: 0x2cb5
11446: 0x2cb6
Преобразование в шестнадцатеричный формат (идентификатор потока, записанный в выходном файле команды jstack, является шестнадцатеричным).
Первый метод преобразования:

$ printf “0x%x” 11447
“0x2cb7”

Второй способ преобразования: добавить 0x к результату преобразования.

在这里插入图片描述

найти стек потоков

$ cat 11441_jstack.txt | grep "GC task thread"
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f971401e000 nid=0x2cb4 runnable
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f9714020000 nid=0x2cb5 runnable
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f9714022000 nid=0x2cb6 runnable
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f9714023800 nid=0x2cb7 runnable

Обнаружено, что все эти потоки выполняют операции GC.

2. Проанализируйте сгенерированный файл GC

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00 100.00  99.94  90.56  87.86    875    9.307  3223 5313.139 5322.446
  • S0: Текущий коэффициент использования зоны выживания 1
  • S1: текущий коэффициент использования Survival Zone 2.
  • E: Коэффициент использования площади Eden Space (Eden)
  • O: Коэффициент использования Old Gen (Старого поколения)
  • M: Коэффициент использования области метаданных
  • CCS: Коэффициент использования сжатия
  • YGC: Количество сборщиков мусора молодого поколения
  • FGC: Количество старых сборок мусора
  • FGCT: сбор мусора для пожилых людей требует времени
  • GCT: общее время, затраченное на сборку мусора.


ФСК встречается очень часто.

3. Проанализируйте сгенерированный снимок кучи

Используйте инструмент Eclipse Memory Analyzer. ссылка для скачивания:woohoo.eclipse.org/toilet/down ОА…

Результаты анализа:

在这里插入图片描述

在这里插入图片描述
См. особенности сложенных больших объектов:
在这里插入图片描述


Общая причина проблемы,OOM, вызванный InMemoryReporterMetrics.
zipkin2.reporter.InMemoryReporterMetrics @ 0xc1aeaea8
Shallow Size: 24 B Retained Size: 925.9 MB

Также можно использовать:Анализ дампа памяти JavaДля анализа, как показано на скриншоте ниже, функция не такая мощная, как МАТ, и некоторые функции нужно заряжать.

在这里插入图片描述

4. Анализ причин и проверка

Из-за этой проблемы проверьте службу, в которой возникла проблема.zipkinНастройка ничем не отличается от других сервисов. Конфигурация оказалась одинаковой.

Затем посмотрите на пакет jar соответствующего zipkin и обнаружите, что рассматриваемая служба зависит отzipkinнижняя версия.

Проблемный сервисzipkin-reporter-2.7.3.jar
Другие сервис-зависимые пакеты без проблем: zipkin-reporter-2.8.4.jar

在这里插入图片描述


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

Причина исследования

Проверьте github zipkin-reporter: найдите соответствующую информацию
GitHub.com/open zip kin/…
Нашел эту проблему ниже:
GitHub.com/open zip kin/…

在这里插入图片描述


Код восстановления и код подтверждения:
GitHub.com/open zip kin/…

Сравните различия между двумя версиями кода:

在这里插入图片描述
Простая демонстрационная проверка:

// 修复前的代码：
  private final ConcurrentHashMap<Throwable, AtomicLong> messagesDropped =
      new ConcurrentHashMap<Throwable, AtomicLong>();
// 修复后的代码：
  private final ConcurrentHashMap<Class<? extends Throwable>, AtomicLong> messagesDropped =
      new ConcurrentHashMap<>();

После исправления используйте это как ключ: Class extends Throwable> вместо Throwable.

Простая проверка:

在这里插入图片描述

在这里插入图片描述

решение

Просто обновите версию zipkin-reporter. Используя следующую конфигурацию зависимостей, импортированныйВерсия zipkin-reporter 2.8.4.

<!-- zipkin 依赖包 -->
<dependency>
  <groupId>io.zipkin.brave</groupId>
  <artifactId>brave</artifactId>
  <version>5.6.4</version>
</dependency>

Небольшое предложение: при настройке параметров JVM добавьте следующие параметры и выведите снимок стека при настройке переполнения памяти.

 -XX:+HeapDumpOnOutOfMemoryError 
 -XX:HeapDumpPath=path/filename.hprof

Справочная статья


Помните OOM, вызванный сыщиком, отправившим исключение zipkin один раз
:woohoo.brief.com/afraid/post8from74943от…

пасхальные яйца


Вложение: Поиск Baidu все еще немного изрыт

在这里插入图片描述

Рекомендуемое чтение:Йивэнь изучает навыки устранения неполадок тупиковой ситуации Java и проблемы с процессором 100%

Спасибо за чтение, если вы найдете этот пост в блоге полезным, пожалуйста, поставьте лайк, чтобы его увидело больше людей! Желаю тебе счастливого дня!


Что бы вы ни делали, пока вы продолжаете это делать, вы увидите разницу! На дороге ни смиренный, ни заносчивый!

Главная страница блога: https://aflyun.blog.csdn.net/

Технологический рай Java-программирования: Публичный аккаунт для обмена техническими знаниями по программированию галантерейных товаров.

Категории