redis-py 8 поставил дефолт `max_connections=100`, а у нас на этом пуле
висят не только команды, но и долгоживущие pub/sub-подписки комнаты — по
одной на каждого участника, пока он в конференции. Сотый участник на
воркер выгребал пул, и WS-хендшейк падал уже на `hgetall` очереди рук с
`MaxConnectionsError`.
Второй потолок того же рода, что и пул БД, только этажом ниже.
Воспроизведён локально: при 99 одновременных WS вход переставал
работать; с `redis_max_connections=500` те же 120 подключений проходят
без единой ошибки. Соединения создаются по мере надобности, поэтому сам
по себе поднятый лимит ничего не стоит.
Пул создавался с дефолтом SQLAlchemy (5 + 10) и под нагрузкой выгребался
за секунды. Теперь параметры заданы явно и вынесены в настройки:
DB_POOL_SIZE=10, DB_MAX_OVERFLOW=10, DB_POOL_TIMEOUT=10. Таймаут снижен с
дефолтных 30 секунд намеренно — пусть запрос падает быстро и показывает
проблему, а не висит полминуты.
Backend запускался одним процессом uvicorn: любой блокирующий вызов
останавливал и параллельные запросы, и WS-чат всех участников. Добавлен
UVICORN_WORKERS с дефолтом 2 — не по числу ядер, потому что на
четырёхъядерном сервере ядра делятся с LiveKit, а медиа важнее API.
Бюджет соединений считается на весь инстанс: каждый воркер держит свой
пул, поэтому UVICORN_WORKERS × (DB_POOL_SIZE + DB_MAX_OVERFLOW) должно
оставаться заметно ниже max_connections у Postgres.
Многопроцессность безопасна: бутстрап настроек в lifespan идемпотентен
(INSERT ... ON CONFLICT DO NOTHING), а WS-чат разносит сообщения через
Redis pub/sub и состояния в памяти процесса не держит.
