Steal time: как понять, что сосед по железу ест ваш процессор

MAATRIX

Сайт на VPS вдруг начал тормозить, а по всем внутренним метрикам процесс работает нормально — запросов немного, память свободна, диск не забит. Первое, что стоит проверить в такой ситуации — не грузит ли ваш физический сервер кто-то другой. В Linux для этого есть отдельная метрика steal time, и она показывает не то, что делает ваш процесс, а то, чего гипервизор ему не дал сделать.

Что такое steal time

Steal time (в выводе top и vmstat — колонка %st или st) — это доля времени, когда вашей виртуальной машине было нужно процессорное время, но гипервизор отдал физическое ядро другой виртуалке на том же хосте. Технически это работает так: у гипервизора (KVM, Xen, VMware — механизм похожий) есть один физический CPU и несколько виртуальных машин, которым он должен раздать время по расписанию. Когда ваша VM готова выполнять инструкции, но гипервизор в этот момент отдал ядро соседней машине — это время засчитывается вашей VM как «украденное» (stolen).

Важно понимать источник цифры: steal time считает не хост, а гостевая ОС внутри VM. Ядро Linux в виртуалке умеет отличать «я не хотел работать» (idle) от «я хотел работать, но мне не дали ядро» (steal) — эта информация приходит через паравиртуальные интерфейсы гипервизора (в KVM это, например, kvmclock/steal-time MSR). На выделенном железе без виртуализации этой метрики просто не существует — там процессор либо ваш целиком, либо нет.

Здесь же стоит отдельно отметить: steal time — это метрика конкретно про CPU. Похожая по духу проблема «шумного соседа» бывает и с диском (когда сосед по хосту забивает I/O), но там симптоматика и диагностика другие — про это подробно в статье медленный диск на VPS: как проверить.

Чем это отличается от обычной загрузки CPU

Разница принципиальная, и её стоит проговорить явно, потому что путаница здесь — источник половины бесполезных попыток «оптимизировать код», когда на самом деле проблема не в коде.

Обычная загрузка CPU (us + sy в top) — это время, которое процессор реально тратит на выполнение ваших инструкций: пользовательский код (us), системные вызовы ядра (sy). Если этот показатель высокий — ваш код или база данных действительно грузят процессор, и решение — оптимизировать запросы, добавить кеширование, либо добавить ядер.

Steal time (st) — это время, когда процессору вообще не давали работать на вас. Ваш процесс не выполнялся не потому, что он медленный или неэффективный, а потому что физическое ядро в этот момент было занято чужой задачей. С точки зрения приложения внутри VM это выглядит как загадочные подвисания: запрос, который обычно выполняется за миллисекунды, вдруг занимает заметно дольше, хотя us+sy невысокие.

Отсюда практический вывод: если у вас высокая нагрузка и высокий us/sy — проблема в вашем софте, тюнингом на уровне приложения можно её решить. Если у вас лаги и жалобы на скорость, а us/sy низкие, зато высокий st — сколько код ни оптимизируй, легче не станет, потому что процессор физически не ваш в этот момент. Это подробно разбирается и в общей статье про диагностику высокая нагрузка на процессор: как найти причину — steal time там один из пунктов, но именно на VPS он часто оказывается главным подозреваемым.

Как увидеть steal time: vmstat и top

Самый простой инструмент — vmstat с интервалом обновления:

vmstat 1

Вывод обновляется каждую секунду, интересующая нас колонка — последняя, st, в блоке cpu:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 512340  81200 934120    0    0     2    18  120  340 12  4 82  0  2
 1  0      0 511980  81200 934300    0    0     0    12  115  330 10  3 84  0  3

Колонки us, sy, id, wa, st — это проценты, которые в сумме должны давать 100. Если st стабильно держится на ненулевом уровне на протяжении многих измерений подряд (а не разово подскочил в один момент) — это сигнал, что гипервизор регулярно отдаёт ваши такты соседям.

В top то же самое видно в строке %Cpu(s) наверху:

%Cpu(s): 12.0 us,  4.0 sy,  0.0 ni, 82.0 id,  0.0 wa,  0.0 hi,  0.0 si,  2.0 st

Если у вас многоядерная VM и нужна разбивка по ядрам, а не усреднённая цифра — в top нажмите 1 (переключение общего вида на построчный по каждому CPU), либо используйте mpstat:

mpstat -P ALL 1

Это полезно, потому что steal time может «прыгать» по ядрам неравномерно — гипервизор не обязан отбирать время у всех виртуальных ядер одинаково.

Если нужна история за более длинный период (а не разовый снимок), на серверах с установленным sysstat можно посмотреть накопленную статистику:

sar -u 1 10

выведет 10 замеров с интервалом в секунду, включая колонку %steal.

Откуда берётся steal time: оверкоммит и шумные соседи

Причина steal time всегда одна и та же по сути: физических ядер на хосте меньше, чем суммарно виртуальных ядер, обещанных всем виртуалкам на этом хосте. Это называется CPU-оверкоммит (overcommit) — распространённая и в целом нормальная практика в виртуализации, потому что большинство VPS большую часть времени простаивают, и хостер может продать больше виртуальных ядер, чем есть физических, статистически рассчитывая, что не все арендаторы одновременно упрутся в потолок.

Проблема начинается, когда оверкоммит слишком агрессивный или когда на одном хосте оказывается один или несколько «шумных соседей» — VPS, которые реально нагружают процессор большую часть времени (майнинг, тяжёлые батчевые задачи, плохо написанный код с busy-loop). В этот момент гипервизору физически не хватает ядер, чтобы обслужить всех, и он начинает урезать время тем, кому «повезло меньше» в очереди планировщика.

Два случая стоит разделять:

• Разовый скачок st на несколько секунд — обычно ничего страшного, кто-то из соседей выполнил тяжёлую, но короткую задачу.
• Стабильно ненулевой st на протяжении часов/дней — это уже характеристика конкретного хоста и тарифа, а не случайность. Такое стоит воспринимать как сигнал, что этот конкретный физический сервер продан «с запасом», рассчитанным на других арендаторов.

Полезно понимать разницу тарифов у хостеров в этом контексте:

Разница между этими вариантами и когда имеет смысл переезжать с VPS на выделенный сервер подробно разобрана в статье выделенный сервер против VPS: когда пора переезжать.

Как отличить steal time от реальной нагрузки на практике

Порядок действий, если приложение тормозит, а вы не уверены в причине:

1. Запустите vmstat 1 (или top) и понаблюдайте минуту-две, а не смотрите на один снимок — единичное измерение может быть случайностью.
2. Смотрите на соотношение us+sy к st. Если основная доля занятого времени — это st, а не us/sy, значит дело не в вашем приложении.
3. Сопоставьте с временем реальных лагов. Если жалобы на медленную работу совпадают по времени с ростом st в логах мониторинга — корреляция достаточно убедительна.
4. Проверьте load average вместе со steal time. Высокий load average сам по себе ничего не говорит о причине — он растёт и от реальной нагрузки, и от процессов, которые ждут украденное время. Как правильно читать эту цифру, разобрано в статье load average: что это число значит на самом деле.
5. Если есть доступ к мониторингу хостера (панель управления часто показывает загрузку по вашей VM отдельно от «видимой изнутри» картины) — сверьте показания. Расхождение между «снаружи всё спокойно» и «изнутри высокая нагрузка» — тоже косвенный признак steal time.
6. Общая диагностика тормозящего сайта (не только steal time, но весь чек-лист — диск, память, сеть) есть в статье сайт тормозит на VPS: диагностика, если хотите проверить все версии по порядку, а не только CPU.

Не существует единого «нормального» порога steal time, который одинаково подходит всем — многое зависит от чувствительности вашего приложения к задержкам. Для фонового batch-задания эпизодический steal time в несколько процентов может быть незаметен, а для сервиса, отвечающего на запросы в реальном времени (веб-API, торговый бот, VoIP), даже кратковременные и небольшие всплески воспринимаются как ощутимые лаги. Ориентируйтесь не на абсолютную цифру, а на то, растёт ли st вместе с жалобами пользователей и держится ли он стабильно, а не разово.

Что делать, если steal time стабильно высокий

Если по итогам наблюдения вы видите, что st не эпизодический всплеск, а постоянный фон — вариантов у вас, по сути, три.

Написать в поддержку хостера и попросить перенос на другой физический хост. Иногда проблема именно в конкретном узле, где скопилось несколько тяжёлых соседей, и миграция VM на менее загруженный хост (без смены тарифа) решает вопрос полностью. Это самый дешёвый вариант — стоит попробовать первым.

Перейти на тариф с гарантированными vCPU у того же хостера, если такой есть. У части провайдеров есть разделение на «обычные» VPS (максимальный оверкоммит, минимальная цена) и тарифы с резервированием ядра — они дороже, но резервирование гарантирует минимум процессорного времени вне зависимости от соседей.

Переехать на выделенный сервер. Если нагрузка вашего проекта такая, что вам нужна предсказуемая производительность процессора постоянно (а не «в среднем»), а не эпизодически — оверселлинг перестаёт быть приемлемым риском в принципе, и решает вопрос только собственное физическое железо, где по определению нет соседей и нет steal time. Это не всегда оправдано по цене для небольшого проекта, но для нагруженного продакшена, где простой стоит дороже разницы в цене — разумный шаг.

Прежде чем принимать решение о переезде, стоит трезво оценить: возможно, часть проблемы всё же в вашем приложении (тогда переезд на более мощное железо ничего не даст), а часть — в steal time. Если после переноса на другой хост или тариф с гарантированными ядрами показатель st уходит в ноль, а лаги остаются — значит, дело было не только в соседях, и стоит дополнительно разобраться с самим приложением.

Частые вопросы