CPU почти пустой. А сервис уже лежит.

Друзья, вышла запись моего доклада с JPoint - "Анатомия зависания: когда thread pool закончился, а CPU почти пустой".

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

В рамках этого доклада мы разбираем обычный Spring MVC-сервис: Tomcat, Hikari, база данных и внешний HTTP-вызов. Никакой экзотической архитектуры.

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

Ресурсы для вычислений есть. Свободных потоков для обработки запросов - уже нет.

Но увидеть этот эффект - только начало. Дальше нужно понять:

• Где именно образовалась очередь: в потоках Tomcat, соединениях к БД или HTTP-клиенте?

• Какие метрики покажут причину, а не просто подтвердят, что пользователю плохо?

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

В докладе мы проходим этот путь на живом сценарии: от зависших запросов до диагностики и исправлений. Чтобы вместо "перезапустили - вроде помогло" был понятный порядок действий.

Что бы вы проверили первым, если сервис не отвечает, а CPU свободен? Держите свой ответ в голове при просмотре.

▶️ "Анатомия зависания" на YouTube

▶️ "Анатомия зависания" на VK