Исчерпание пула: утечки и почему больший пул не спасёт

Сервис работает часами, затем медленно каждый запрос начинает таймаутить на «unable to acquire connection». Рестарт чинит — на несколько часов, затем возвращается по расписанию. Это не нагрузка; это утечка. Где-то путь кода берёт соединение и на определённой ветке — обычно ветке ошибки — никогда не возвращает. Каждый раз, как та ветка бежит, пул навсегда теряет одно соединение. Пул на 20 переживает 20 утечек и затем мёртв, сколь бы мал ни был трафик. Фикс, к которому все тянутся первым — сделать пул больше — лишь меняет утечку с 3-часового отказа на 6-часовой.

Утечка — это взятие без возврата

Контракт пула прост: каждое взятие должно быть уравновешено возвратом. Утечка — нарушение контракта: соединение взято и затем на каком-то пути никогда не освобождено. Классический виновник — путь ошибки, пропускающий очистку:

const conn = await pool.acquire();
const rows = await conn.query(sql);   // бросает здесь
conn.release();                       // недостижимо — утекло

Когда query бросает, исполнение прыгает мимо release(), и то соединение ушло из пула навсегда. Пул не знает, что заёмщик его бросил; с его точки зрения соединение всё ещё «взято, в использовании». Каждый прогон той ветки ошибки убирает ещё одно соединение из обращения. Вот почему утечка выглядит медленной бомбой: трафик нормален, затем за часы доступное число тикает вниз к нулю, и каждый запрос начинает падать — симптом идентичен массовому перегрузу, но причина — несколько строк кода на невезучей ветке.

Фикс структурный, не большие числа: гарантируй освобождение через try/finally (или языковую конструкцию, делающую то же — using, defer, контекст-менеджер, скоупнутую транзакцию фреймворка):

const conn = await pool.acquire();
try {
  return await conn.query(sql);
} finally {
  conn.release();   // бежит на успехе И на броске
}

Почему больший пул не чинит утечку

Рефлекс, когда соединения кончаются — поднять размер пула. Против утечки это хуже, чем бесполезно — оно превращает быстрый, очевидный отказ в медленный, загадочный, и не останавливает кровотечение. Здесь есть глубже, контринтуитивный результат: даже меры устойчивости показывают резко убывающую отдачу против утечек. Исследование влияния утечек нашло, что подъём пула с 5 до 100 соединений — 20× рост — улучшил скорость снижения отказов лишь с 96,8% до 62,8% — суть в том, что бросать соединения в проблему покупает куда меньше, чем намекает рост размера, потому что ровная скорость утечки осушает любой пул; ты лишь поменял, как долго до пустоты. Единственный реальный фикс — перестать течь и обнаруживать утечки рано.

Обнаруживай утечки и следи за правильными метриками

Поскольку утечки тихи до катастрофы, защита — наблюдаемость:

• Порог обнаружения утечки. Пул может предупредить, когда соединение удерживается дольше, чем должен любой легитимный запрос (HikariCP leakDetectionThreshold, напр. 2 с). Соединение, вне дольше этого, почти наверняка утекло или застряло на патологически медленной операции — в любом случае хочешь знать, со стектрейсом того, кто его взял.
• Четыре датчика пула. Следи за active (в использовании), idle (свободно), total и waiting (потоков в очереди за соединением). Здоровый пул держит idle > 0 большую часть времени. Утечка показывается как active, лезущий вверх и не падающий назад; исчерпание показывается как idle, пришпиленный на 0, и waiting, лезущий вверх. Алертуй на idle около 0 и waiting > 0 устойчиво — они предшествуют отказу.

Ловушка async-границы

Тонкая современная причина: удержание пулевого соединения через await чего-то иного, чем база. Если взять соединение и затем await медленного внешнего HTTP-вызова до запроса, ты держишь дефицитное соединение простаивающим на длительность вызова — не утекло, но захоменено. Под нагрузкой это исчерпывает пул прямо как утечка, потому что эффективная конкурентность теперь ограничена самым медленным, через что ты держишь соединение. Правило: бери соединение как можно позже, держи его лишь на работу с базой и никогда не оборачивай несвязанный сетевой вызов внутрь взятия.