В среде виртуализации гостевая система показывает низкую загрузку CPU, но растут задержки и показатель steal time. Какой вывод о возможном узком месте следует сделать?
Вероятное узкое место находится не внутри приложения, а на уровне физического хоста или гипервизора: виртуальная машина не получает запрошенное процессорное время. Низкая загрузка CPU внутри гостя в таком случае не означает наличие свободного вычислительного ресурса.
Steal time показывает время, когда виртуальная машина была готова выполняться, но гипервизор отдал физический CPU другой виртуальной машине. Поэтому рост задержки вместе с ростом steal time указывает на конкуренцию за физические процессоры или на неудачное размещение виртуальной машины.
В физическом сервере потребление CPU обычно оценивают по времени, когда процессор занят выполнением задач операционной системы и приложения. С распространением виртуализации один физический процессор стали делить несколько гостевых систем, поэтому гостевая ОС получила дополнительное состояние: время, отнятое гипервизором.
Без отдельной метрики это время могло выглядеть как простой период бездействия гостевой ОС. Показатель steal time появился как способ отличить отсутствие готовых к выполнению задач от ожидания виртуальной машиной доступа к физическому CPU.
Низкий процент CPU в госте может привести команду к ошибочному выводу, что процессор не влияет на производительность. В результате увеличивают число потоков приложения, усложняют код или ищут проблему в базе данных, хотя виртуальная машина фактически получает процессор с задержками.
Особенно опасна такая ошибка для сервисов с жёсткими требованиями к задержке. Средняя загрузка может оставаться небольшой, но нерегулярное изъятие CPU увеличивает очереди на выполнение, задерживает обработку запросов и ухудшает высокие перцентили, например p95 и p99.
Нужно сопоставить во времени steal time, задержки запросов, пропускную способность и показатели физического хоста. Если при росте steal time увеличиваются задержки, а приложение не показывает собственного насыщения CPU, гипотеза о конкуренции за физический процессор становится обоснованной.
Следует проверить несколько уровней:
Важно не трактовать любой рост steal time как автоматическое доказательство единственной причины деградации. Он может совпасть по времени с сетевыми задержками, сборкой мусора или блокировками приложения. Поэтому необходима временная корреляция и контрольный прогон на менее загруженном хосте или на выделенном физическом ресурсе.
Увеличение числа виртуальных CPU не всегда устраняет проблему. При высокой конкуренции оно может увеличить количество запросов к физическому планировщику и не дать выигрыша, а иногда усилить задержки синхронизации. Более надёжные варианты — устранить конкурирующую нагрузку, изменить размещение виртуальной машины, обеспечить CPU-гарантии или повторить тест на хосте с достаточным резервом.
Во время теста API его средняя загрузка CPU внутри виртуальной машины составляла 35%, но p99 вырос с 300 миллисекунд до 1,8 секунды. Команда сначала увеличила пул рабочих потоков, однако это не изменило результат: потоки чаще ожидали планирования, а не выполняли полезную работу.
Рассматривались три варианта. Увеличение числа виртуальных CPU было быстрым, но не гарантировало получение дополнительного физического времени. Перенос базы данных не соответствовал наблюдениям, поскольку задержки росли одновременно с steal time, а показатели базы оставались стабильными. Перенос виртуальной машины на менее загруженный хост требовал организационных изменений, но непосредственно проверял гипотезу о конкуренции за CPU.
Выбрали перенос и повторили тест с теми же профилем нагрузки и данными. После снижения steal time высокие перцентили вернулись к прежнему уровню без изменения кода и количества виртуальных CPU. Это подтвердило, что узким местом была доступность физического процессора, а не номинальная загрузка CPU внутри гостя.
1. Достаточно ли увидеть высокий steal time, чтобы объявить CPU единственным узким местом?
Нет. Высокий steal time доказывает, что виртуальная машина теряет часть запрошенного процессорного времени, но не доказывает, что именно это полностью объясняет деградацию. Нужно проверить совпадение по времени с ростом задержек и очередей, а также исключить независимые изменения в сети, хранилище и зависимостях.
Кроме того, важны не только средние значения. Краткие всплески изъятия CPU могут почти не изменить средний steal time, но заметно ухудшить p99. Поэтому анализ должен включать временные ряды и распределение задержек, а не один усреднённый показатель.
2. Чем steal time отличается от обычного idle time гостевой системы?
При idle time у гостевой ОС нет готовой работы, которую нужно выполнять на CPU. При steal time работа есть, но гипервизор временно не предоставляет виртуальной машине физический процессор.
Оба состояния могут выглядеть как невысокая загрузка CPU, однако последствия различаются. Рост idle time обычно означает наличие вычислительного резерва, а рост steal time при готовых задачах указывает на внешний дефицит процессорного ресурса.
3. Почему увеличение числа виртуальных CPU может не улучшить задержку?
Дополнительные виртуальные CPU помогают только при наличии соответствующего физического ресурса и достаточной параллельности приложения. Если физические ядра уже заняты другими виртуальными машинами, новые виртуальные CPU будут конкурировать за то же ограниченное время выполнения.
Кроме того, более крупная виртуальная машина может сложнее планироваться на перегруженном хосте. Поэтому изменение размера необходимо проверять повторным тестом, одновременно контролируя steal time, физическую загрузку хоста и перцентили задержки.