Анатомия зависания: когда thread pool закончился, а CPU почти пустой

Почему сервис «умирает», когда по CPU все спокойно, в логах почти нет ошибок, а память в порядке?

Разберем типовой Spring MVC-сервис в универсальной трехзвенной архитектуре (Transport → Business → Data/Integration) и пройдем путь стандартного запроса «под капотом»: Tomcat выдает рабочий поток, Hikari — соединение к БД, затем выполняется исходящий HTTP-вызов, где поток продолжает заниматься ожиданием.

На живом сценарии покажем, как рост latency у внешней зависимости превращается в рост конкурентности, как копится очередь в пулах и почему именно поэтому CPU часто не растет, хотя пользователю уже плохо.

Затем построим минимальный, но достаточный набор наблюдаемости по методологиям RED и USE и научимся отличать «симптомы» (p95/p99/RPS) от причины (saturation/queueing в потоках, коннектах или HTTP-клиенте). Дадим практичный плейбук диагностики: куда смотреть первым, вторым, третьим — вместо «пересобрать и перезапустить».

После этого разберем исправления, которые работают в стандартном Spring MVC: корректные таймауты (connect/read/connection-request), ограничение параллелизма на внешние вызовы (bulkhead), выравнивание лимитов между Tomcat/Hikari/HTTP-клиентом, fail-fast и graceful деградация. Отдельно обсудим алерты: почему важно ловить saturation и рост очередей раньше, чем пользователи начнут жаловаться, и какие пороги ставить.

В конце вы получите чек-лист «чтобы больше не повторилось» и понимание, как объяснить команде, почему «CPU свободен, но сервис не живой».