Разбор инцидента: несколько часов деградации PostgreSQL в проде
The author and colleagues run a service that uses an internal instance of Arize Phoenix, an LLM observability system. Phoenix relies on PostgreSQL as its database. The database had usually been stable, with Average Active Sessions around 1.0 on a 2-vCPU instance. The post is an incident breakdown covering several hours of PostgreSQL degradation in production.
Всем привет. Я с коллегами пишу сервис, который использует внутренний инстанс публичного приложения Arize Phoenix (система LLM-observability — наблюдаемости за LLM-приложениями). Arize Phoenix использует в качестве БД PostgreSQL. СУБД обычно жила спокойно: AAS (Average Active Sessions — среднее число одновременно активных сессий: выполняющих запрос или ожидающих ресурса) держался около 1.0 на инстансе с 2 vCPU (виртуальными ядрами процессора). Однажды случилась аномалия: AAS взлетел до 25. Как я разбирался с этой проблемой