Почему при загрузке сервера 90% время ответа растёт в разы, хотя запас ещё есть?
- Что такое закон Литтла?
- Как утилизация влияет на задержку?
- Почему нельзя держать серверы загруженными на 95%?
Запросы приходят неравномерно, и при высокой загрузке они ждут в очереди. Время ожидания растёт как ρ / (1 − ρ): при 50% загрузки ожидание равно времени обработки, при 90% — в 9 раз больше, при 99% — в 99.
- Закон Литтла: L = λ · W — запросов в системе = поток × время в системе
- Задержку определяет не средняя загрузка, а очереди при всплесках
- Отсюда запас мощности 30–50%, автомасштабирование заранее и ограничение очередей
А ещё Тот же закон даёт размер пула: потоков = RPS × время ответа
Подробно
Почему возникает очередь, если сервер не загружен на 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) и задержку — они связаны через очередь.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Ожидание растёт как ρ / (1 − ρ)
- ✗Время ожидания в очереди растёт линейно с загрузкой
- ✗При 90% загрузки ожидание всего на 10% больше времени обработки
- ✗Запас мощности не нужен, если средняя загрузка ниже 100%
Что спросят дальше
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.