Сервер приложений загружен на 30% по CPU, но задержки растут, а пул соединений к базе занят полностью. Что даст добавление ещё нескольких серверов приложений?
- Почему добавление серверов не ускоряет сервис?
- Как найти узкое место?
Ничего хорошего: узкое место — база (пул соединений занят, CPU приложения свободен). Новые экземпляры добавят соединений и конкуренции за ту же базу — может стать даже хуже.
- Масштабируют узкое место, а не то, что удобно масштабировать
- Насыщение (очереди, занятость пулов) предсказывает проблему раньше утилизации
- Дальше: медленные запросы, блокировки, долгие транзакции, внешние вызовы с занятым соединением
А ещё Типичный порядок узких мест: база → внешние синхронные вызовы → сеть → CPU приложения
Подробно
Диагноз. CPU приложения 30% — оно в основном ждёт. Пул соединений занят полностью — запросы стоят в очереди за соединением. Значит, база обрабатывает запросы медленнее, чем они приходят, или соединения удерживаются слишком долго.
Почему больше экземпляров не поможет: у каждого свой пул, база получит ещё больше одновременных соединений. Если она упирается в CPU, диск или блокировки, лишний параллелизм только увеличит переключения и конкуренцию — задержка вырастет.
Что проверить:
- медленные запросы (
pg_stat_statements, EXPLAIN) — индексы, N+1; - блокировки и долгие транзакции,
idle in transaction; - держит ли код соединение во время внешних HTTP-вызовов — частая причина «пустых» занятых соединений;
- размер пула относительно возможностей базы (закон Литтла: соединений = запросов в секунду × время удержания);
- метрики базы: CPU, диск, ожидания (wait events).
Что делать: оптимизировать запросы, сократить время удержания соединения, кэшировать чтение, вынести чтение на реплики, PgBouncer, вертикально масштабировать базу.
Метод USE (utilization, saturation, errors) для каждого ресурса помогает найти узкое место системно.
Что хотят услышать
- Вывод: узкое место в базе, новые экземпляры не помогут.
- Насыщение против утилизации.
- Что проверить и как исправить.
Частые ошибки
- Увеличивать пул соединений «чтобы не ждали».
- Масштабировать приложение по привычке.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Пропорционально снизит задержку, так как нагрузка распределится
- ✗Снизит загрузку CPU до 15% и тем самым ускорит ответы
- ✗Удвоит пропускную способность при удвоении числа серверов
- ✓Ничего или хуже: узкое место — база, новые серверы усилят борьбу за соединения
Что спросят дальше
- Почему деградация под нагрузкой не линейна?
- Что бы вы сделали с базой в этой ситуации?
Разбор темы
- Оценка нагрузки и ресурсов
Как считать на салфетке: QPS из аудитории, пиковые коэффициенты, объём хранения и трафик, порядки задержек, узкое место и типичные ошибки оценки на интервью.
Связанные вопросы
- Зачем нужен пул соединений к базе и как выбрать его размер? Middle
- Почему удвоение числа серверов не удваивает пропускную способность? Senior
- Почему при загрузке сервера 90% время ответа растёт в разы, хотя запас ещё есть? Middle
- Сервис работает на двадцати инстансах. Добавление ещё десяти не уменьшает время ответа. Как вы будете искать причину и что предпримете? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.