Сегодня я периодически получал аварийный сигнал от платформы управления. Загрузка ЦП слишком высока, а старая загрузка jvm слишком высока. В это время я поспешил выяснить причину. Ниже приводится запись моего процесса расследования. могут быть неправильные места.Приветствую всех.Пожалуйста, поправьте меня.Вы также можете общаться с нами о подобных случаях.Посмотрим, как я проходил это расследование.
Вызовите полицию
- Аварийный сигнал высокой загрузки ЦП, близкий к 100%
- Затем пришла старая высокая тревога jvm
Процесс устранения неполадок
- Сначала откройте платформу мониторинга, чтобы увидеть загрузку ЦП тревожного узла.
- Войдите на сервер, чтобы найти информацию о стеке потоков, которая занимает слишком много ресурсов ЦП.
①ПройтиtopКоманда для нахождения максимальной загрузки ЦПpid[идентификатор процесса]
Найдите pid 1469
②Пройтиtop -Hp pidПроверьте процесс с высокой загрузкой процессораtid[идентификатор темы]
③ пройтиprintf pid |grep tid Преобразование идентификатора потока в шестнадцатеричный формат
④Пройтиjstack pid | grep tid -A 30Найдите информацию о стеке потоков
Есть два потока, которые занимают слишком много ресурсов ЦП, один из которых предназначен для печати журнала исключений (новый объект), а поток gc
распечатать стек исключений
Этот занятый процессор можно найти в соответствии с информацией о стеке, посмотрите на код, вы можете найти новый объект и распечатать полную информацию о стеке.
Где ExceptionUtils.getFullStackTrace(e) принадлежит пакету commons.lang
Можно обнаружить, что два вышеуказанных метода создают много объектов, а информация о стеке печати занимает память.
поток gc
Можно обнаружить, что потоки, которые занимают слишком много ресурсов ЦП, выполняют много операций gc.
- пройти черезjstat -gcutil интервал pidПосмотреть информацию о JC
Можно обнаружить, что район Эдема и старости заполнены, и было проведено много ФСК.
Введение в индикаторы
S0: Процент используемой мощности первой выжившей области молодого поколения (выжившего)
S1: Процент емкости, используемой второй оставшейся областью молодого поколения.
E: Процент используемой мощности кампуса молодого поколения Eden (Eden)
O: Процент используемой мощности в старом поколении
P: Процент занятости генерирующих мощностей в Перми
YGC: количество gc молодого поколения с момента запуска приложения до текущего времени выборки.
YGCT: время от запуска приложения до сборщика мусора молодого поколения в текущем времени выборки.
FGC: количество старых gcs от запуска приложения до текущего времени выборки.
FGCT: время от запуска приложения до gc старого поколения в текущее время выборки.
GCT: общее время, затраченное на gc от запуска приложения до текущей выборки.
- Экспортируйте файл дампа и проанализируйте его с помощью jvisualvm.exe, который поставляется с jdk.
использоватьjmap -dump:live,format=b,file=name.dump pidЭкспортируйте файл дампа, как правило, файл дампа будет относительно большим [мои 2,94 ГБ], а затем загрузите [вы можете использовать sz name.dump] для локального использования jvisualvm [jdk поставляется в каталоге bin] анализ
Сначала посмотрите на сводку файла дампа
Посмотрите, что это за большие объекты
Обнаружено, что первые несколько больших объектов связаны с объектом ElastaicSearchStatusException, а затем платформа управления использует es только в одном месте, то есть для создания воронки данных для записи шагов, на которых поиск рекламы отфильтровывается, чтобы упростить продукты и операции, чтобы проверить причины отфильтрованных рекламных объявлений, а затем открыть код
Среди них метод поиска RestClientFactory.getRestClient().search(searchRequest) следовал шаг за шагом и находил место, где было выброшено исключение ElasticSearchStatusException.
Метод parseResponseException вызовет исключение ElasticSearchStatusException. Что касается того, какой шаг выдается в этих двух местах, вы можете продолжить изучение оценки кода es или удаленной отладки. Я оставлю это здесь в покое. В любом случае, мы можем знать, что существует проблема с эс
На самом деле, именно из-за того, что здесь выдается исключение, создается большое количество объектов, потому что исключение также будет создавать объекты в том месте, где печатается журнал исключений, как указано выше, а старость занята слишком много, что приводит к большому количеству fgc
Но почему здесь исключение?
Я вошел в платформу управления es, чтобы проверить индекс es, и обнаружил, что некоторые индексы не были созданы.Создание индекса было создано задачей создания и записи данных в режиме реального времени.Я обнаружил, что задача остановлена.
обработка
- Найдите соответствующую задачу для перезапуска, найдите причину остановки задачи, восстановите, а также создайте и восстановите потерянный индекс.
- Лучше всего добавить управление потоком в печать журнала исключений [управление с помощью Guava.RateLimiter]
резюме
Идеи по устранению неполадок, связанных с чрезмерной занятостью старой области jvm
- сверху, чтобы просмотреть процессы, которые занимают много ресурсов процессора
- jstat -gcutil pid interval для просмотра статуса gc
- jmap -dump:live,format=b,file=name.dump файл дампа экспорта pid
- Анализ файлов дампа с помощью VisualVM
Идеи по устранению неполадок, связанных с высокой загрузкой процессора
- сверху для просмотра pid процесса, занимающего процессор
- top -Hp pid для просмотра идентификатора потока tid, который занимает слишком много ресурсов ЦП в процессе.
- printf '%x/n' tid to hex
- jstack pid |grep tid hex -A 30 Просмотр расположения информации о стеке
Добро пожаловать в официальный аккаунт [Белые зубы каждый день], получайте свежие статьи, давайте общаться и добиваться успехов вместе!