CPU steal time: как измерить, как доказать и когда он ни при чём. В логах пусто, загрузка процессора умеренная, а приложение отвечает вдвое медленнее обычного. Один из кандидатов на объяснение — steal time: время, когда виртуальная машина была готова считать, но не получила физическое ядро.

Метрика простая на вид и очень легко используется неправильно. Ниже — как она устроена, как снять её так, чтобы результат что-то значил, и почему высокий steal сам по себе ещё не диагноз.

Как steal вообще появляется Гипервизор раздаёт физические ядра между виртуальными машинами. Когда планировщик гостевого ядра ставит задачу на vCPU, а гипервизор в этот момент отдал физическое ядро другой машине, гостевое ядро видит, что время прошло, а работа не выполнялась. Эта разница и учитывается как steal.

Отсюда важное следствие: steal измеряется изнутри гостя и всегда является косвенной оценкой. Гость не знает, почему ему не дали ядро. Причин минимум четыре:

• конкуренция с соседними VM на ноде;

• ограничение по CPU на уровне тарифа (квота), которое гипервизор применяет к вам;

• накладные расходы самого планировщика гипервизора;

• кратковременные всплески — миграция VM, резервное копирование ноды, обслуживание.

Где steal не виден вообще? Если у вас контейнерная виртуализация (lxc, openvz), steal time не появится никогда — механизма для него нет, ядро общее с хостом. Проверить:

systemd-detect-virt

Аналог steal для контейнеров — троттлинг по cgroup:

grep -E 'nr_throttled|throttled_usec' /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max

Растущий nr_throttled означает, что вы выбираете свою квоту. Это не соседи и не оверселлинг — это ваш лимит, и решается он либо оптимизацией, либо тарифом.

Какие значения считать нормой. Универсальной нормы нет — она зависит от платформы виртуализации, политики провайдера и тарифа. Практические ориентиры, которые у меня обычно работают:

• 0–1% — фон, встречается почти везде, игнорируем.

• 3–5% — повод посмотреть динамику и сопоставить с задержками приложения. Само по себе не проблема.

• выше 10% устойчиво — заметно влияет на латентно-чувствительные сервисы: API, realtime, базы под нагрузкой. Пакетную обработку может почти не задевать.

Ключевое слово — устойчиво. Смотрите значение за 10–15 минут, а не пиковый выброс. Разовый скачок до 30% на две секунды не значит ничего.

Как отличить соседей от собственной квоты. Единственный надёжный способ — сопоставить steal с вашей нагрузкой.

Постройте два ряда за сутки: steal и ваш собственный CPU usage (us + sy). Дальше:

• Steal растёт вместе с вашей нагрузкой и падает вместе с ней — почти наверняка вы упираетесь в квоту тарифа. Провайдер тут ни при чём.

• Steal приходит независимо от вашей активности, в том числе ночью при простое, — это внешняя конкуренция.

• Steal ровным фоном 2–3% круглосуточно — накладные расходы платформы, обычно нормально.

Без исторических данных этот анализ невозможен, поэтому sysstat стоит поставить заранее, а не в момент инцидента.

Что передавать в поддержку? Обращение вида «у меня высокий steal» почти всегда возвращается с просьбой уточнить. Работает такой набор:

• вывод sar -u 1 600 или график за несколько часов;

• mpstat -P ALL 1 за минуту — с разбивкой по ядрам;

• ваша собственная загрузка CPU за тот же период, чтобы показать отсутствие корреляции;

• конкретные временные метки, когда приложение деградировало;

• systemd-detect-virt и параметры тарифа.

Что не поможет

• Оптимизация кода. Если ядро вам не выдают, эффективность вашего кода на steal не влияет.

• Добавление vCPU. Иногда даже ухудшает: больше vCPU — больше конкуренции за планирование, особенно на переподписанной ноде.

• Перезагрузка. Помогает только если приводит к переезду на другую ноду, и это лотерея.

Чек-лист

systemd-detect-virt                          # есть ли steal в принципе
vmstat 1                                     # характер: плато или выбросы
mpstat -P ALL 1                              # распределение по ядрам
sar -u 1 600                                 # устойчивость за 10 минут
grep throttled /sys/fs/cgroup/cpu.stat       # для контейн