Ответ
Высокий показатель %st (steal time) в утилите top сигнализирует о проблеме на уровне виртуализации. Он показывает процент времени, в течение которого виртуальная машина (ВМ) была готова к выполнению, но гипервизор не мог выделить ей физическое CPU-ядро, потому что оно было занято другой ВМ на том же хосте.
Практические последствия для сервисов:
- Непредсказуемая производительность: Сервисы на ВМ будут испытывать «голод» по CPU, что приводит к росту задержек (latency) и может вызвать таймауты.
- Нарушение SLO/SLA: Колебания в доступности CPU делают невозможным гарантирование стабильного времени отклика.
Причины и мои действия по устранению:
- Перегрузка физического хоста: Это самая частая причина. Решение — обсудить с инженерами платформы миграцию ВМ на менее загруженный хост или вертикальное масштабирование (увеличение vCPU/памяти, если гипервизор позволяет).
- Некорректные лимиты ВМ: Проверить настройки ВМ. Например, в KVM/qemu можно увеличить параметры
cpu_sharesилиvcpu. - «Шумные соседи»: Другая ВМ на том же хосте может монополизировать ресурсы из-за ошибки конфигурации или атаки. Требуется анализ со стороны администраторов гипервизора.
Как я это отслеживаю:
Вместо разовых проверок top я настраиваю сбор этой метрики в Prometheus с помощью node_exporter (метрика node_cpu_seconds_total{mode="steal"}) и устанавливаю алерт при продолжительном высоком значении (например, >10% за 5 минут).
# Пример просмотра steal time для всех CPU
$ cat /proc/stat | grep -E "^(cpu|cpu[0-9]+)"
cpu 1500 100 500 8000 200 0 50 300 0 0
# Последнее число в строке 'cpu' (после 'guest_nice') — это steal time в USER_HZ (обычно 1/100 секунды).
# Здесь 300 единиц = 3 секунды steal time.