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.
Виртуальная машина может показывать низкую загрузку 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.