В ночь на четверг сервер столкнулся с очень странным явлением: при доступе к трафику загрузка процессора поднималась до 100%, но использование памяти было невелико, и сервер автоматически восстанавливался NGINX, обрезав поток и не принимая HTTP-запросы. .Шаги, которые изначально планировали плыть вовремя, были опутаны проблемами =-=
Итак, мы начали входить на рассматриваемый сервер и изучать конкретную проблему с помощью журналов и мониторинга. До и после обрезки потока служба сообщений ActiveMQ и RPC-вызовы DUBBO работают.Разница в том, что загрузка ЦП до обрезки потока внезапно увеличилась до 100%, но увеличилось только использование памяти, а не OOM. так что нет файла дампа).
Начать просмотр сервера:
1: Через верхний сервер найдите процесс jvm с PID 30284, который занимает 100% ЦП.
2: Показать список потоков, отсортированных по потокам с высокой загрузкой ЦП.
[admin@xxxxx]# top -Hp 30284
3: Найдите PID наиболее трудоемкого потока и преобразуйте его в шестнадцатеричный формат.
[admin@xxxxx]# printf "%x\n" 31448 77e0
4: Просмотрите подробную информацию о стеке потоков jvm и grep, занимающих много времени, с помощью команды jstack.
[admin@xxxx] # jstack 30284 | grep 77e0 -A 60
дальнейший анализ
Существует много информации о стеке. Поток MQ находится в состоянии TIME_WAIT, ожидая удаления сообщения из очереди. Наблюдая за исходным кодом, выясняется, что здесь он выполнял вычисления, но MQClient ждал сообщения для обработки, так что это состояние, похоже, не проблема =-=
При просмотре бизнес-журнала обнаруживается, что потребление сообщений onMessage занимает особенно много времени.
Обработка некоторых сообщений превысила 100000мс, что вообще ненормально (ಥ_ಥ).По сравнению с несколькими другими серверами, такое же приложение, но скорость обработки сообщений в норме, и другие показатели тоже в норме.Переключать можно только этот сервер сначала. , изначально есть подозрение, что есть особая проблема с потреблением MQ этим сервером.
Кроме того, я отследил несколько использованных сообщений и обнаружил, что метод запроса к базе данных занимает особенно много времени, что приводит к более медленной обработке всего сообщения.
Глядя на обработку сообщений других серверов, этот метод запроса занимает одну-две секунды, но это нормально. Но на медленную скорость запросов этой машины должна влиять высокая загрузка ЦП сервера, в конце концов, соединения redis и JDBC также будут затронуты.
Сервер временно отключен, а после завершения обработки сообщения сервер автоматически восстанавливается, однако «виновник», вызвавший увеличение загрузки процессора сервера, не найден, и объяснить его невозможно. Нам нужно продолжать наблюдения.
резюме:
1. Изучите серверные команды, которые просто определяют, что делает ресурсоемкий поток. 2. Промежуточное программное обеспечение сообщений ActiveMQ все еще незнакомо, и его необходимо понять. 3. Запрос на уровне dao выполняется медленно, и бизнесу необходимо оптимизировать этот сценарий. 4. Чтобы понять влияние различных состояний сервера
Использованная литература:
1,Подробное объяснение и решение сервера TIME_WAIT и CLOSE_WAIT