CPU steal time у VPS: як знайти noisy neighbour

Що насправді вимірює CPU steal time

CPU steal time — це частка часу, протягом якого ваш віртуальний CPU був готовий виконуватися і не мав причин чекати, але гіпервізор передав фізичне ядро іншій гостьовій системі. Робота стояла в черзі. Ядро було зайняте іншим завданням. Linux обліковує ці цикли окремо та показує їх як st. Так можна відрізнити ситуацію, коли «мій сервер зайнятий», від ситуації, коли «мій сервер чекає своєї черги».

Саме для цього існує цей лічильник. Час, який ваші процеси фактично виконуються на CPU, показується як us (user) або sy (system). Час, протягом якого завдання заблоковане в очікуванні сховища, показується як wa (I/O wait). vCPU (віртуальний CPU), який готовий до виконання, перебуває в черзі виконання, не має незавершених операцій I/O, але все ще не виконується, показується як st. Ніщо всередині вашого сервера не може усунути цей стан, оскільки рішення про планування приймається рівнем нижче — на хості.

Це безпосередньо пов’язано з тим, як VPS використовує одну фізичну машину спільно з багатьма гостьовими системами. Зазвичай причина — сусідній гість: інша гостьова система на тому самому вузлі активно використовує ресурси, тому хост розподіляє ядра між вами. Є й друга причина, яку часто не враховують. Багато провайдерів обмежують shared vCPU часткою фізичного ядра, і в кількох гіпервізорах це примусове обмеження обліковується всередині гостьової системи як steal. Тому високе значення st показує, що ядро не було передане вам. Але воно не завжди показує, хто його зайняв.

Звідки береться значення steal

Ядро не може самостійно вимірювати steal, оскільки не бачить хост. Це значення передає гіпервізор. У KVM хост записує окремий лічильник для кожного vCPU на сторінку пам’яті, спільну з гостьовою системою, а гостьова система підсумовує його, якщо ядро зібрано з CONFIG_PARAVIRT_TIME_ACCOUNTING, як і всі ядра дистрибутивів. Xen передає ті самі дані через область runstate. Загальне значення потрапляє в userspace лише в одному місці:

head -1 /proc/stat

Цей рядок cpu містить десять лічильників у тіках USER_HZ від моменту завантаження системи в такому порядку: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal — восьме значення після мітки. Усі наведені нижче інструменти, vmstat, top, mpstat і будь-який Prometheus exporter читають це саме поле та перетворюють два зразки на відсоткове значення.

Важливіше за інші наслідки те, що станеться, якщо гіпервізор не експортує цей лічильник. Поле назавжди залишиться нульовим, а кожен інструмент на його основі показуватиме спокійний 0.0, навіть якщо хост перевантажений. KVM і Xen експортують цей лічильник. Гостьові системи у VMware і Hyper-V часто постійно показують нуль. Перш ніж довіряти нульовому значенню, перевірте платформу:

systemd-detect-virt

Команда виводить назву платформи, наприклад kvm, xen, vmware або microsoft, а на фізичному сервері — none. У контейнері вона натомість показує середовище виконання, наприклад lxc, docker або podman. Це характеризує контейнер, а не базову машину. У kvm нуль є реальним свідченням того, що хост не створює для вас проблем. На платформі, яка ніколи не заповнює це поле, нуль не є доказом нічого, тому навантаження потрібно оцінювати за тривалістю виконання реальної роботи.

Як перевірити steal time CPU на VPS?

vmstat входить до складу пакета procps. Він є майже в кожному образі Ubuntu і Debian для VPS, але може бути відсутній у деяких мінімальних образах контейнерів, тому встановіть його до того, як покладатися на цей інструмент.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version виводить рядок на кшталт vmstat from procps-ng 4.0.4. Якщо цей рядок виведено, інструмент встановлений, а ви читаєте реальні лічильники ядра. Після цього vmstat 1 5 знімає один зразок на секунду п’ять разів.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Знайдіть стовпець st у блоці cpu праворуч. Поточні збірки procps-ng виводять після нього стовпець gu для часу KVM guest, тому st є другим праворуч, а не останнім. Читайте стовпець за назвою заголовка, оскільки його позиція змінювалася між версіями.

Дотримуйтеся двох правил, щоб правильно інтерпретувати показники. Перший рядок даних містить середнє значення від моменту завантаження, тому проігноруйте його й читайте наступні рядки. Один зразок не є вимірюванням, оскільки steal time виникає сплесками: запустіть vmstat 1 60 і спостерігайте повну хвилину, перш ніж робити висновок.

top повідомляє те саме число у своєму підсумковому рядку %Cpu(s), у полі з позначкою st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Щоб переглянути дані окремо для кожного ядра, додайте sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat виводить один рядок для кожного CPU зі стовпцем %steal. Він показує, чи affected усі vCPU, чи лише один. Щоб зберегти історію для звернення до служби підтримки, записуйте зразки у файл, а не лише переглядайте їх на екрані:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Запускайте цю команду через cron протягом годин, коли ви підозрюєте проблему. Тоді файл дасть змогу замінити повідомлення провайдеру «учора ввечері все працювало повільно» точними даними за десять хвилин.

Що означають значення steal?

• Стабільне значення 0.0. Система працює нормально, або платформа взагалі не звітує про steal. Перш ніж робити висновки, перевірте це за допомогою systemd-detect-virt.
• Сплески на кілька відсотків тривалістю кілька секунд. Це нормально для будь-якого shared node. На сусідньому віртуальному сервері запускається збірка або хост виконує резервне копіювання.
• Стабільні 1–5 відсотків у shared plan. Це очікувано. Вартість відображає використання спільного CPU.
• Стабільні 5–10 відсотків. Сповільнення, яке можна виміряти. Почніть збирати докази й порівнюйте ті самі години протягом кількох днів.
• Понад 10 відсотків протягом кількох годин. Для вашого навантаження на node недостатньо ресурсів через надмірну підписку. Це рівень, за якого варто звернутися до support або перенести систему.

Розглядайте ці діапазони як орієнтир, а не як специфікацію, оскільки жоден провайдер не гарантує певний рівень steal у shared plan. Оцінюйте їх з урахуванням своїх завдань. Нічне пакетне завдання може працювати за 15 відсотків steal, і це залишиться непомітним. Сервіс, чутливий до затримки, покаже проблему в p99 задовго до того, як середнє значення стане тривожним. Саме тому на спеціалізованих ядрах мають працювати навантаження, чутливі до затримки, наприклад торгові боти.

Скільки коштує вам steal time?

Розрахунок простий. Якщо частка s вашого CPU time вилучається, завдання, якому потрібен фіксований обсяг CPU time, виконується в 1 / (1 - s) разів довше за годинником. Для завдання, якому потрібно 60 секунд CPU time:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

За значення 3 відсотка, типового для shared plan, це завдання виконується 61.9 секунд замість 60.0. Через це ніхто не відкриває ticket. За значення 8 відсотків потрібно 65.2 секунд. За значення 40 відсотків тому самому завданню потрібно 100.0 секунд, і черга, яка раніше спорожнювалася, починає зростати.

Це розрахункові значення, а не результати вимірювань. Модель передбачає один runnable thread і рівномірний розподіл steal протягом інтервалу. Реальні сервіси часто працюють гірше, ніж показує крива, оскільки stolen slice припадає на середину запиту, а затримку потім відчувають усі операції, що очікують на цей запит. Щоб отримати власне значення, а не лише формулу, виконайте benchmark VPS протягом спокійної години, а потім повторіть його в період високого навантаження, записавши st для обох інтервалів.

Це steal чи щось інше?

Steal легко сплутати з іншими симптомами. Читайте лічильники разом, в одному рядку vmstat.

• st має високе значення, а r і us залишаються низькими: хост не надає вам ядро. Це steal.
• r значно перевищує кількість ваших vCPU, us має високе значення, а st близький до нуля: ви запускаєте більше роботи, ніж можуть виконати ваші власні CPU. Порівняйте r з виводом nproc. Це ваша власна oversubscription, а не сусідня віртуальна машина.
• wa має високе значення, а st близький до нуля: завдання заблоковані через сховище. Це інша проблема, яка потребує іншого виправлення.
• Load average має високе значення, а st і us низькі: показник load також враховує uninterruptible tasks. Тому зазвичай це вказує на завислий пристрій або мережеве монтування, яке не відповідає, а не на проблему з CPU.

Burstable plans потребують окремого пояснення. Вони надають баланс кредитів, який накопичується під час простою та витрачається під час навантаження. Коли баланс вичерпується, провайдер обмежує вас базовою швидкістю. На деяких платформах це обмеження відображається як steal. На інших його не видно зсередини, і ви просто отримуєте менше циклів за секунду. Прочитайте опис плану, перш ніж вирішувати, що проблема на боці сусіда.

Чому контейнер не показує steal time

Steal є характеристикою віртуальної машини, а не контейнера, запущеного всередині неї. Docker-контейнер на власному VPS використовує спільний /proc хоста, тому значення st, зчитане всередині контейнера, є steal time VPS. Саме це вам і потрібно. Контейнерна віртуалізація, яку продають як VPS, працює інакше. Якщо використовується lxcfs, значення /proc/stat усередині контейнера формується на основі обліку cgroup, тому steal time за визначенням дорівнює нулю. Стек моніторингу, який збирає дані лише з контейнера, може показувати стабільний нуль, хоча фізичній машині не вистачає ресурсів.

У контейнері лічильником із тим самим практичним значенням є throttling за CPU quota. У cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled рахує періоди контролю, протягом яких група досягала встановленої CPU quota, а throttled_usec підсумовує час, протягом якого її виконання було призупинено. Зростання nr_throttled означає, що процес був готовий до виконання, але не отримував CPU. Це схоже на steal time, але спричинене обмеженням, яке ви встановили самостійно. Перевірте власні ліміти, перш ніж звинувачувати хост, особливо якщо ви запускаєте свої сервіси в Docker на VPS з CPU limits у compose-файлі. Багаторівнева віртуалізація додає ще одне місце, де втрачається час, оскільки VM усередині VPS враховує steal time VPS і власну затримку планування. Пам’ятайте про це, якщо ви використовуєте вкладену віртуалізацію на VPS.

Що робити за тривалого steal

Жодне налаштування всередині гостьової системи не усуне steal, оскільки рішення приймає планувальник поза межами гостьової системи. Оновлення kernel також нічого не змінить: планування з урахуванням кешу, додане в Linux kernel 7.2, перерозподіляє ваші завдання між фактично наданими вам ядрами й не може повернути такти, які вже забрав сусідній інстанс. Є 4 дієві кроки.

Спочатку зберіть докази. Записуйте часові мітки в UTC, тривалість кожного епізоду, частоту повторення та те, чи mpstat показує проблему на одному vCPU або на всіх. Тиждень записаних вимірювань цінніший за знімок екрана.

Створіть тикет із цими даними. Поставте 2 прямі запитання: чи перевантажений цей node у зазначені проміжки часу та чи можна перенести мій інстанс. Додайте в тикет вивід vmstat і точний час. Провайдери реагують на відтворюваний часовий інтервал, а на тикет із повідомленням, що сервер повільний, зазвичай відповідають запитом надати такий інтервал. Обсяг роботи, який можна передати провайдеру, є однією з практичних відмінностей між керованим і некерованим VPS.

Попросіть виконати міграцію. Перенесення гостьової системи на менш завантажений node є звичайною операцією для провайдера й зазвичай потребує короткого перезавантаження. Це безкоштовне виправлення, яке вирішує поширений випадок, коли на одному node одночасно розміщено кілька ресурсомістких сусідніх інстансів.

Усуньте конкуренцію за ресурси платним способом. План із dedicated vCPU резервує фізичні ядра для вашого інстансу, тому лічильник залишається на нулі. Щомісячна плата буде вищою, але це правильний вибір для навантаження, яке не може компенсувати нестабільну продуктивність. Якщо цього все одно недостатньо або ви хочете мати окремий доступ і до memory bandwidth, наступним кроком буде dedicated server замість VPS.

Поки ви очікуєте на будь-який із цих варіантів, зменште вплив steal. Запускайте менше worker threads, ніж маєте vCPU, оскільки потоки, які не можуть отримати ядро, лише збільшують кількість перемикань контексту. Перенесіть batch-роботи на години, коли node не завантажений; це видно з вашого журналу. Потім повторіть вимірювання тією самою командою протягом тих самих годин, щоб визначити результат змін, а не робити припущення.

FAQ

Який показник CPU steal time є нормальним для VPS?

У shared-плані короткочасні піки та стабільне значення до приблизно 5 відсотків є звичайними, оскільки shared CPU означає, що хост розподіляє фізичні ядра між гостьовими системами. Стабільне двозначне значення протягом кількох годин не є нормальним і потребує звернення до служби підтримки. У плані з dedicated vCPU очікуване значення — 0.0, тому будь-який інший показник слід повідомити провайдеру як несправність. Оцінюйте це значення з урахуванням власного навантаження: нічне пакетне завдання може працювати зі значним steal time, тоді як API, чутливий до затримок, цього не допускає.

Чи усуне більший план високий steal time?

Ні, не сам по собі. Більша кількість vCPU на тому самому shared-вузлі означає більшу кількість віртуальних CPU, які конкурують за ті самі завантажені фізичні ядра, тому відсоток може залишитися незмінним. Steal time усуває dedicated CPU allocation або перенесення на менш завантажений вузол. Більша частка завантаженої машини все одно залишається часткою завантаженої машини.

Чому мій VPS показує 0 steal time, хоча він явно працює повільно?

Є дві поширені причини. Гіпервізор може взагалі не експортувати цей лічильник. Це типово для платформ VMware і Hyper-V, тому поле залишається нульовим незалежно від навантаження на хості. Виконайте systemd-detect-virt, щоб визначити платформу. В іншому разі вузьке місце розташоване в іншому місці: перевірте wa на очікування операцій зі сховищем, порівняйте r із nproc, щоб виявити власне перевантаження, і перегляньте /sys/fs/cgroup/cpu.stat усередині контейнерів для виявлення обмеження квоти.

Чи можу я зменшити steal time всередині свого сервера?

Ви не можете змінити планування на хості зсередини гостьової системи. Можна лише зменшити його вплив. Запускайте менше worker threads, ніж маєте vCPU, щоб у run queue накопичувалося менше роботи в очікуванні ядра, яке не звільняється. Переносьте пакетні завдання на години, коли вузол менш завантажений. Кешуйте результати, щоб запитам рідше були потрібні CPU. Зміни, які справді усувають steal time, — перенесення на інший вузол або виділення dedicated cores — може виконати лише провайдер.