Как контролировать количество соединений с базой данных при высокой нагрузке в FastAPI

Что проверяют

Понимаете ли вы, что предел соединений задаёт база, а не приложение, и что считать его нужно на все воркеры и поды сразу. Следом спрашивают, что происходит, когда пул исчерпан, и как не держать соединение во время медленного внешнего вызова.

Как отвечать

Начните с арифметики: в PostgreSQL по умолчанию max_connections = 100, а у каждого процесса uvicorn или gunicorn свой пул. Четыре пода по четыре воркера с pool_size=10 и max_overflow=10 дают до 320 соединений, база столько не выдержит.

• пул SQLAlchemy: в create_async_engine с драйвером asyncpg задайте pool_size и max_overflow (по умолчанию 5 и 10), pool_timeout (ожидание свободного соединения, по умолчанию 30 секунд), pool_pre_ping=True против мёртвых соединений и pool_recycle;
• сессия на запрос: зависимость с yield и async with вокруг async_sessionmaker(), чтобы соединение вернулось в пул даже при исключении. Сессия берёт соединение при первом запросе к базе и отдаёт после коммита или закрытия;
• не блокировать цикл: синхронный драйвер внутри async def останавливает весь event loop. Нужен либо асинхронный драйвер, либо обычный def, который FastAPI выполнит в пуле потоков;
• внешний пулер: PgBouncer в режиме transaction держит на стороне базы десятки соединений при тысячах клиентских. С asyncpg за ним отключают кеш подготовленных выражений (statement_cache_size=0 в connect_args) либо включают поддержку prepared statements в самом PgBouncer;
• ограничение сверху: asyncio.Semaphore на тяжёлые запросы и быстрый отказ с кодом 503 лучше, чем очередь на полминуты;
• мониторинг: pg_stat_activity по состояниям, включая idle in transaction, метрики занятости пула и число таймаутов ожидания.

Где спотыкаются

Считают пул на одно приложение и забывают умножить на воркеры, реплики и фоновые задачи вроде Celery, которые ходят в ту же базу.

Держат сессию открытой на время HTTP-запроса к внешнему сервису или отдачи стрима. Пул пустеет уже при умеренном трафике.

Ставят max_overflow=-1 или огромный pool_size, думая, что это лечит таймауты. Проблема просто переезжает в базу, которая начинает отказывать всем.