Сначала разделите время ожидания соединения, собственно SQL и сетевую часть. Низкий CPU БД не исключает locks, насыщение пула, I/O или изменившийся маршрут после Kubernetes deployment.
После развёртывания в Kubernetes p95 запросов к PostgreSQL вырос с 40 до 900 мс, хотя CPU базы не перегружен. Откат релиза затронет важный исправленный сценарий. Что проверишь первым и почему?
Сначала разделите время ожидания соединения, собственно SQL и сетевую часть. Низкий CPU БД не исключает locks, насыщение пула, I/O или изменившийся маршрут после Kubernetes deployment.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала разделите время ожидания соединения, собственно SQL и сетевую часть. Низкий CPU БД не исключает locks, насыщение пула, I/O или изменившийся маршрут после Kubernetes deployment.
Сравните pool-метрики приложения, активные транзакции, wait events и длительность того же SQL со стороны сервера. Проверьте число pods × pool size, DNS/TLS, прокси и сетевые потери. Ищите отличие конфигурации от прежней среды. Вместо слепого отката выберите минимальное подтверждённое исправление, сохранив важный сценарий и план безопасного восстановления.