Решил проблему парящего процессора, наконец-то я могу спать спокойно

Java
Решил проблему парящего процессора, наконец-то я могу спать спокойно

поиск проблемы

Вот в чем дело.В последнее время проект, отвечающий за Xiaomazai, планируется обновить в 2:00 утра. Несколько дней назад Miss Test провела стресс-тест на сайте и наблюдала за различными показателями, такими как ЦП, память, загрузка, RT и QPS сервиса.

Во время стресс-теста женщина-испытатель обнаружила, что у одного из наших интерфейсов после увеличения числа запросов в секунду до 400 резко возросла загрузка ЦП.

Я больше не здесьCPU,内存,load,RT,QPSЯ буду вдаваться в подробности, ведь если какой-то из этих пунктов будет обсуждаться, статья может быть не закончена. Маленькая милашка, заинтересованная в углубленном исследовании, может проверить это самостоятельно.

Здесь я толькоQPSиCPU利用率Сделайте краткий обзор.

❝

Частота запросов QPS в секунду, QPS — это мера того, сколько трафика обрабатывает конкретный сервер запросов в течение заданного времени. Чем выше QPS, тем больше трафика обрабатывает сервер в данный момент времени.

❞
❝

Загрузка ЦП используется для описания использования ЦП, что указывает на ситуацию, когда ЦП занят в течение определенного периода времени. Чем выше коэффициент использования, тем больше программ машина запускает в это время, и наоборот.

❞

Зная эти два основных момента, давайте посмотрим, как я это позиционирую.

выявить проблему

После проверки обратной связи младшей сестры по этой проблеме, я вошел на сервер, сделал следующее:

1. Найдите процесс

Войдите на сервер и выполните команду top, чтобы проверить загрузку ЦП:

$top
   PID  USER      PR   NI  VIRT   RES    SHR   S  %CPU   %MEM   TIME+  COMMAND
  44529 root     20   0  4289m   874m  13312  S  123.0   10.9   10:39.73  java

topКоманда для просмотра ранжирования всех процессов, занимающих ЦП системы.Это распространенный инструмент анализа производительности в Linux.Он может отображать состояние занятости ресурсов каждого процесса в системе в режиме реального времени, подобно диспетчеру задач Windows.

Давайте посмотрим, что представляют собой эти индикаторы:

    PID — 进程id
    USER — 进程所有者
    PR — 进程优先级
    NI — nice值。负值表示高优先级，正值表示低优先级
    VIRT — 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
    RES — 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
    SHR — 共享内存大小，单位kb
    S — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
    %CPU — 上次更新到现在的CPU时间占用百分比
    %MEM — 进程使用的物理内存百分比
    TIME+ — 进程使用的CPU时间总计，单位1/100秒
    COMMAND — 进程名称（命令名/命令行）

выполнивtopКоманда, я увидел, что использование процессора процесса Java с процессом ID 44529 достигла 123%. Он может в основном располагаться, что наше приложение Java вызывает использование целого сервера CPU всего сервера.

2. Позиционирующая нить

Конечно, Java является однопроцессным и многопоточным, поэтому я посмотрел на использование ЦП каждым потоком в процессе Java с PID = 44529, а также использовал команду top:

$top -Hp 44529
   PID  USER     PR   NI  VIRT  RES     SHR   S  %CPU   %MEM    TIME+  COMMAND
  44580 root     20   0   4289m 874m   13312  S  16.2   10.9    3:02.96   java

выполнивtop -Hp 44529Команда, я обнаружил, что в процессе 44529 поток с идентификатором 44580 занимает больше всего ЦП.

3. Код позиционирования

С помощью команды top я обнаружил конкретный поток, вызывающий высокую загрузку ЦП, а затем я должен посмотреть, в какой строке кода возникла проблема.

Сначала я преобразовал поток 44580 в шестнадцатеричный:

$printf %x 44580
ae24

Далее, в соответствии с стеком журнала в шестнадцатеричном значении для печати представления запроса по положению потока проживает. и черезjstackКоманда для просмотра информации о стеке:

$jstack 44529 |grep -A 200 ae24
"System Clock" #28 daemon prio=5 os_prio=0 tid=0x00007efc19e8e800 nid=0xae24 waiting on condition [0x00007efbe0d91000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at java.lang.Thread.sleep(Thread.java:340)
    at java.util.concurrentC.TimeUnit.sleep(TimeUnit.java:386)
    at com.*.order.Controller.OrderController.detail(OrderController.java:37)  //业务代码阻塞点

В приведенном выше коде мы ясно видим, что может быть проблема в строке 37 OrderController.java.

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

Суммировать

Выше описан весь процесс устранения неполадок. В основном используются:top,printf,jstackи другие инструкции.

  1. использоватьtopКоманда для просмотра PID процесса, который в данный момент занимает высокий процессор;

  2. Просмотрите PID потока текущего процесса, потребляющего ресурсы:  top -Hp PID

  3. Преобразуйте PID потока в шестнадцатеричный формат и запросите напечатанный журнал стека в соответствии с шестнадцатеричным значением, чтобы проверить местоположение метода, в котором находится поток.

  4. пройти черезjstackКоманда, проверьте информацию о стеке, этот шаг в основном способен обнаружить большинство проблем.

Разгромить

Проект вышел в онлайн в 2:00 сегодня утром. Вчера вечером я работал сверхурочно. Я просто поспал два часа, когда утром пришел домой. Тестирование края). Поэтому я встал и написал эту статью, которую можно считать записью первой сверхурочной работы в 2020 году.

Наконец, спасибо за чтение. Цель статьи — зафиксировать и поделиться, если в статье есть явные ошибки, пожалуйста, указывайте на них, и мы будем учиться вместе в ходе обсуждения. Большое тебе спасибо !

Если вы считаете, что эта статья была для вас полезной, то поставьте ей лайк, ваша поддержка и поддержка являются для меня движущей силой двигаться вперед~

Добро пожаловать, чтобы обратить внимание на мой публичный аккаунт WeChat [маленький программист], давайте вместе обсудим код и жизнь.

Категории