Пулинг: диагностируй и укроти исчерпанный pool

Возьми небольшой HTTP-сервис на реальном pool Postgres или MySQL, намеренно загони его в pool starvation и в connection-leak exhaustion, затем приведи к здоровому установившемуся состоянию — правильно размеренный pool, fail-fast acquisition, без leaks, свежие соединения — доказывая каждый шаг датчиками active/idle/total/waiting.

• Построй или возьми небольшой HTTP-сервис на любом языке с реальным connection pool (HikariCP, pgx/database-sql, node-postgres и т.п.) против локального Postgres или MySQL. Выстави хотя бы один эндпоинт, запускающий запрос, и один, держащий соединение через намеренно медленную операцию.
• Подключи наблюдаемость pool: выставь четыре датчика — active (в работе), idle (свободные), total и waiting (потоки в очереди за соединением) — плюс acquisition wait time и leak-detection threshold (например, HikariCP leakDetectionThreshold ~2 с). Логируй или граф'и их во времени.
• Воспроизведи starvation: с acquisition timeout, оставленным на дефолтных 30 с, нагрузи медленный эндпоинт, пока все соединения не станут заняты. Зафиксируй датчики (idle прижат к 0, waiting растёт) и покажи, как upstream-потоки пиннятся, пока слой не перестанет принимать запросы.
• Воспроизведи leak: добавь хендлер, чей error-путь пропускает release() (без try/finally), затем направь трафик, бьющий по этому пути. Покажи, как active растёт и не падает, idle ратчетится к 0, и что рестарт временно лечит — сигнатура leak, а не overload.
• Размерь pool по железу: вычисли (cores x 2) + spindles для машины базы, выставь maximum-pool-size соответственно и нагрузочно протестируй для нахождения точки насыщения — поднимай конкурентность, пока пропускная способность не выйдет на плато, затем сядь на наименьший pool, достигающий пика.
• Ограничь ожидание и гарантируй return: сократи acquisition timeout до примерно 1–3x обычного запроса, чтобы истощённый pool падал быстро, и оберни каждый borrow в try/finally (или using/defer/context manager), чтобы release выполнялся при успехе и при throw.
• Защити lifecycle: выставь maxLifetime строго ниже wait_timeout / idle-лимита базы, включи validation on borrow и подтверди, что первый запрос после наведённого простоя успешен, а не падает с reset.
• Перезапусти идентичные нагрузочные тесты для starvation и leak-пути и запиши числа «после» рядом с «до»; leak-путь теперь должен показывать возврат active к базовой линии, а starvation — падать быстро с ограниченным waiting, а не пиннить веб-слой.

• Таблица до/после четырёх датчиков (active, idle, total, waiting), acquisition wait p99 и request p99 — измеренные под одинаковой нагрузкой, а не оценённые, для сценариев starvation и leak.
• Leak доказуемо устранён: с фиксом try/finally active возвращается к базовой линии после остановки трафика по error-пути, и leak detection не выдаёт предупреждений под устойчивой нагрузкой.
• Pool размерен под (cores x 2) + spindles (или под измеренную точку насыщения), и короткий нагрузочный тест показывает, что он достигает пика пропускной способности при меньшей задержке, чем вдвое больший pool на том же железе.
• Абзац-разбор: какой рычаг починил каждый сценарий (size, acquisition timeout, try/finally, maxLifetime) и почему увеличение pool было неверным инстинктом для leak.