Получить доступ

Почему при загрузке сервера 90% время ответа растёт в разы, хотя запас ещё есть?

MiddleЗадержка, пропускная способность и очереди
Ещё спрашивают так:
  • Что такое закон Литтла?
  • Как утилизация влияет на задержку?
  • Почему нельзя держать серверы загруженными на 95%?
Коротко

Запросы приходят неравномерно, и при высокой загрузке они ждут в очереди. Время ожидания растёт как ρ / (1 − ρ): при 50% загрузки ожидание равно времени обработки, при 90% — в 9 раз больше, при 99% — в 99.

  • Закон Литтла: L = λ · W — запросов в системе = поток × время в системе
  • Задержку определяет не средняя загрузка, а очереди при всплесках
  • Отсюда запас мощности 30–50%, автомасштабирование заранее и ограничение очередей

А ещё Тот же закон даёт размер пула: потоков = RPS × время ответа

Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.

Попробуйте сами

Очередь и утилизация: почему при 90% всё тормозит

Подробно

Почему возникает очередь, если сервер не загружен на 100%. Запросы приходят случайно: иногда три подряд, иногда пауза. В паузу сервер простаивает — это время потеряно, а пачку приходится обрабатывать по очереди. Чем выше загрузка, тем реже паузы, в которые очередь успевает рассосаться.

Модель M/M/1 (случайный поток, случайное время обработки, один обработчик) даёт:

  • среднее время в системе W = S / (1 − ρ), где S — время обработки, ρ — загрузка;
  • при ρ = 0,5 → W = 2S; ρ = 0,8 → 5S; ρ = 0,9 → 10S; ρ = 0,99 → 100S.

Кривая похожа на хоккейную клюшку: до 60–70% почти ровно, после 80% резкий рост. Реальные системы с несколькими обработчиками (M/M/c) ведут себя лучше — больше рабочих делят одну очередь, — но характер тот же. А хвост (p99) растёт ещё сильнее среднего.

Закон Литтла: L = λ · W. Среднее число запросов в системе равно интенсивности потока, умноженной на среднее время пребывания. Работает для любой устойчивой системы, без предположений о распределениях. Применения:

  • 2000 RPS × 50 мс = 100 запросов одновременно — столько нужно потоков или соединений к базе;
  • если пул соединений 20, а запрос держит соединение 100 мс, предел — 200 RPS к базе, дальше — очередь;
  • рост времени ответа зависимости в 3 раза при той же нагрузке утроит число занятых потоков — так одна медленная зависимость съедает пул.

Практические выводы:

  • держать запас: целевая загрузка CPU 50–70%, а не 95%;
  • автомасштабирование по задержке или длине очереди, а не только по CPU, и с запасом на время запуска новых экземпляров;
  • уменьшение времени обработки работает вдвойне: снижает и S, и ρ;
  • очереди ограничивать — бесконечная очередь при перегрузке означает бесконечную задержку (backpressure, load shedding);
  • изменчивость вредна: тяжёлые запросы вперемешку с лёгкими дают хвосты — их разводят по разным пулам.

Пример

Сервис: 8 потоков, обработка 40 мс → предел 8 / 0,04 = 200 RPS.
При 100 RPS (ρ = 0,5) — ждать почти не приходится.
При 180 RPS (ρ = 0,9) — среднее время в несколько раз выше, p99 — в десятки.
При 210 RPS очередь растёт без ограничения: каждую секунду +10 запросов.

Что хотят услышать

  • Причина очереди: неравномерный поток и простой в паузах.
  • Нелинейный рост задержки, формула или хотя бы форма кривой.
  • Закон Литтла и пример расчёта пула.
  • Выводы: запас мощности, ограниченные очереди, масштабирование по задержке.

Частые ошибки

  • «Пока CPU не 100%, всё хорошо».
  • Путать пропускную способность (RPS) и задержку — они связаны через очередь.

Что спросят дальше

Связанные вопросы

Закрытая бета

Подсказки на собеседовании — в реальном времени

sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.

  • Промокод на 2 часа — сверх пробных 30 минут
  • Программа для Windows — скачать сразу, войти — через Яндекс ID или VK ID
  • Прямая связь с разработчиком: что улучшить — сделаем