Исчерпание пула и idle-in-transaction: сценарий отказа в 3 ночи

В 02:14 срабатывает алерт PgBouncer: pool = 24, cl_waiting = 180. Приложение возвращает 503. pg_stat_activity показывает 19 backend’ов в состоянии “idle in transaction” с максимальным возрастом 8 минут. Пул был правильно настроен этим утром.

Что на самом деле означает исчерпание пула

Исчерпание пула происходит, когда каждый backend в пуле занят и новое соединение не может быть получено. На уровне приложения: pool.acquire() таймаутит или отклоняется. На уровне Postgres: backend’ы за этими занятыми соединениями находятся в одном из состояний:

• active — выполняет медленный запрос или ждёт блокировки
• idle in transaction — между операторами внутри BEGIN, который не был COMMIT или ROLLBACK
• idle — действительно простаивает (тогда почему пул полон? ответ: неверный pool_size или утечка соединений)

Пул исчерпан в смысле отсутствия свободных слотов. База данных не исчерпана — она ждёт приложение.

Четыре корневые причины

1. Долгие запросы — отсутствующий индекс делает запрос за 5 с; при 1 000 QPS это 5 000 соединений в полёте. Исправление: EXPLAIN ANALYZE, добавить индекс, пагинировать большие сканы.

2. Idle-in-transaction — самая частая. Приложение открыло транзакцию (BEGIN) и не выполнило COMMIT или ROLLBACK: необработанное исключение, внешний API-вызов внутри транзакции, отсутствие try/finally. Backend сидит “idle in transaction”, удерживая блокировки, MVCC-снапшот и слот пула.

3. Всплеск трафика — спрос превышает размер пула при стабильной нагрузке. Исправление: reserve_pool_size в PgBouncer, автомасштабирование на уровне приложения, или очередь с деградацией (возвращать 503 с Retry-After до исчерпания пула).

4. Внешняя зависимость внутри транзакции — вызов Stripe, загрузка в S3, доставка вебхука — всё внутри BEGIN…COMMIT. Транзакция остаётся открытой на время внешнего вызова. Если тот сервис замедляется, каждая транзакция в полёте удерживает слот пула секунды или минуты.

Idle-in-transaction — двойной сбой

Backend в состоянии idle in transaction удерживает:

1. Слот пула — виден немедленно; вызывает исчерпание пула
2. Блокировки строк — заблокированные строки не могут быть изменены другими транзакциями
3. MVCC-снапшот — VACUUM не может очистить мёртвые кортежи старше xmin этого backend’а; таблицы раздуваются

Один баг, открывающий транзакцию и забывающий COMMIT на пути ошибки, может опустошить 20-соединённый пул за секунды и вызвать раздутие таблиц, нарастающее часами.

Диагностика исчерпания пула за пять шагов

Страховочная сеть: idle_in_transaction_session_timeout

Этот Postgres GUC убивает любой backend, который остаётся в idle in transaction дольше порогового значения:

ALTER SYSTEM SET idle_in_transaction_session_timeout = '60s';
SELECT pg_reload_conf();

При таком значении сценарий со Stripe из хука превращается в: таймауты Stripe вызывают прерывание отдельных транзакций (залогированных, алертируемых), а не исчерпание пула. Пул выживает; приложение логирует 504 и повторяет попытку.

Это бесплатная страховочная сеть. Каждое production-развёртывание Postgres должно её иметь. Устанавливайте значение выше вашей самой долгой легитимной транзакции (обычно 30–120 с для OLTP).