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

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

Steal time CPU — це частка часу, коли ваш віртуальний 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, тому 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. Він показує, чи зачеплено всі 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. Це очікувана ситуація. Вартість тарифу відображає використання shared CPU.
• Стабільні 5–10 відсотків. Сповільнення, яке можна виміряти. Почніть збирати докази та порівнюйте ті самі години протягом кількох днів.
• Понад 10 відсотків протягом кількох годин поспіль. Для вашого навантаження на node виділено недостатньо ресурсів. Це рівень, за якого варто звернутися до служби підтримки або перенести навантаження.

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

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

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

[
  {
    "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 відсотка, типового для спільного тарифного плану, це завдання виконується за 61.9 секунд замість 60.0. Через це ніхто не створює тікет. За значення 8 відсотків це 65.2 секунд. За значення 40 відсотків тому самому завданню потрібно 100.0 секунд, і черга, яка раніше спорожнювалася, починає зростати.

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

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

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

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

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

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

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

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

cat /sys/fs/cgroup/cpu.stat

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

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

Жодне налаштування всередині guest не усуває steal, оскільки рішення приймає scheduler поза guest. Реальними є чотири дії.

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

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

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

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

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

FAQ

Який steal time на VPS є нормальним?

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

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

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

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

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

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

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