Взятие и таймауты: очередь ожидания — настоящий дроссель задержки

Downstream-запрос, обычно занимающий 5 мс, замедляется до 500 мс во время инцидента. За секунды каждое соединение в пуле занято одним из этих медленных запросов. Следующий запрос просит соединение, а свободных нет — поэтому он ждёт. У пула дефолтный таймаут взятия 30 секунд, поэтому он ждёт до 30 секунд до отказа. Теперь запросы копятся за пустым пулом, каждый держит поток веб-сервера в заложниках 30 секунд, и пул потоков тоже наполняется. База была лишь медленной; таймаут взятия превратил медленную в лежащую, потому что никто не решил, сколько запрос должен быть готов ждать.

Взятие не всегда мгновенно

Счастливый путь — «взять соединение, оно свободно, выполни запрос». Но у фиксированного пула есть второе состояние: все соединения заняты. Когда так, взятие не ошибётся и не создаст магически новое соединение — оно блокирует, ставя вызывающего в очередь ожидания, пока соединение не вернут или не сработает таймаут. Это ожидание невидимо в обычное время, потому что пул редко пуст, но это важнейшее поведение для понимания, потому что каждый связанный с пулом сбой живёт здесь.

Так что общее время запроса — больше не просто время в очереди на базе; теперь это время ожидания соединения + время запроса. Под нагрузкой часть «ожидание соединения» может затмить сам запрос, и она полностью скрыта, если не мерить отдельно.

Таймаут взятия — дроссель задержки

Таймаут взятия (HikariCP connectionTimeout, дефолт 30 секунд) — сколько вызывающий просидит в очереди ожидания до того, как пул сдастся и бросит исключение. Это число — не деталь безопасности, оставляемая по умолчанию, это намеренный бюджет задержки на худший случай. Задать его хорошо значит выбрать, что должно случиться, когда пул голодает:

• Слишком долго (напр. дефолт 30 с). Запросы ждут малую вечность. Каждый ждущий держит вышестоящий ресурс — рабочий поток веб-сервера, HTTP-соединение — всё время. Пул пустеет, затем пул потоков наполняется ждущими, затем сервис перестаёт принимать запросы вообще. Одна медленная зависимость каскадирует в полный отказ.
• Слишком коротко (напр. 50 мс). Запросы падают в миг, когда пул кратко полон, включая нормальные микровсплески, которые очистились бы за 60 мс. Ты превращаешь временное давление в поток ошибок.
• В точку (часто 1–3× времени обычного запроса, напр. несколько сотен мс до ~2 с). Достаточно долго, чтобы пережить нормальный всплеск, достаточно коротко, чтобы реальное голодание упало быстро и освободило вышестоящий поток на что-то полезное — вернуть 503, сбросить нагрузку, разомкнуть breaker.

Пайл-ап — петля обратной связи

Опасная часть пустого пула в том, что он самоусиливающийся. Медленные запросы держат соединения дольше → пул осушается → новые запросы встают в очередь → эти запросы держат вышестоящие потоки, пока в очереди → вышестоящий ярус насыщается → повторы наваливают ещё запросов → база, теперь под ещё большим давлением, становится ещё медленнее. Каждый шаг ухудшает следующий. Вот почему малый всплеск задержки на зависимости может стать полным отказом минутами позже: поведение ожидания пула усиливает его. Защиты все про ограничение ожидания: вменяемый таймаут взятия, отдельно мониторимая метрика «потоков ждёт» и быстрый отказ, чтобы вышестоящая ёмкость не потреблялась обречёнными ждущими.