Не трафика. Не памяти. Просто коннекты к БД закончились.
Как это работает: приложение общается с базой через соединения - как телефонные линии. У облачных баз есть лимит (Oracle Cloud: 300, CloudSQL: зависит от тарифа). Каждый запрос может занять одно. Звучит безобидно, пока не перестаёт.
История #1:
Делали Cloudways Autonomos (WordPress-хостинг с автоскейлингом). Использовали CloudSQL. Первое нагрузочное тестирование - видим: лимит коннектов всё ближе и ближе.
Хорошо, что поймали по метрикам, а не когда всё рухнуло в проде.
Решение: CloudSQL Proxy + connection pooling.
История #2 (свежая):
У клиента Oracle Cloud DB. Лимит: 300 коннектов.
Месяцами работало нормально. Потом в понедельник утром: мёртв. Никаких ошибок. Никаких предупреждений. Просто перестал отвечать.
Смотрю метрики: 333 активных соединения. Прибито к максимуму.
Пробую перезагрузить инстанс БД - зависает.
Саппорт час вручную реанимировал. Вернулись к жизни: 4 коннекта. Четыре. Из трёхсот.
Что идёт не так:
- “Мы маленькие, у нас такого не будет” (размер не важен - важно, как приложение работает с БД)
- SaaS-база = бесконечный ресурс (спойлер: нет)
- Нет мониторинга на БД, потому что “это же managed”
- Нет connection pooling в приложении
Что помогает:
- Connection pooling (PgBouncer, ProxySQL, облачные прокси)
- Правильные таймауты в приложении
- Мониторинг + алерты на количество коннектов (даже на SaaS)
- Кэш-слой, чтобы разгрузить БД
Идеальную архитектуру с первого раза не сделаешь. Но отслеживать connection count - это не опция, это базовая наблюдаемость.
А у вас какие были “ой всё” моменты с базами?
Делитесь в комментах - будем учиться на чужих граблях, а не только на своих 👇