steal time: как VM понимает, что CPU забрала виртуализация

Виртуальная машина может показывать низкую загрузку CPU, но при этом работать медленно.

Причина может быть в том, что vCPU просто не получает физический CPU: гипервизор в этот момент выполняет другую VM. Это время Linux называет steal time.

1️⃣Проверяем steal time

grep '^cpu ' /proc/stat

Или:

vmstat 1

В vmstat это колонка st:

procs -----------memory---------- ---cpu---
 r  b   swpd   free   buff  cache   us sy id st
 4  0      0  ...    ...    ...     35  8 42 15

st=15 означает, что около 15% времени vCPU не мог выполняться, потому что физический CPU был отдан кому-то ещё.

2️⃣Почему это отличается от обычной загрузки
Допустим, приложение хочет работать постоянно:

VM хочет CPU
      ↓
vCPU готов выполняться
      ↓
гипервизор не даёт ему pCPU
      ↓
steal time растёт

При этом внутри VM процесс может выглядеть вполне здоровым: нет большого iowait, нет высокой загрузки памяти, а задержки растут.

3️⃣Что с этим делают сейчас

Свежая серия steal_governor предлагает использовать steal time непосредственно для scheduler’а гостя. При высоком steal time VM уменьшает набор preferred CPUs, фактически добровольно сокращая число используемых vCPU. Когда steal снижается, CPUs возвращаются обратно.

Например, пороги в текущей серии:

steal > 5% → убрать core из preferred set
steal < 2% → вернуть core

Идея в том, что иногда лучше иметь меньше реально работающих vCPU, чем много vCPU, которые постоянно конкурируют за физические CPU. Особенно это важно, если вытесненный vCPU в этот момент держал lock.