Steal time на VPS: как проверить ожидание процессора в Linux

Во время импорта каталога магазин отвечает медленно, но ни один процесс внутри VPS не выглядит особенно занятым. У виртуальной машины есть ещё один возможный источник задержки: её виртуальный процессор готов работать, а физический процессор пока не предоставлен. В Linux часть такого ожидания отражает steal time. Сначала стоит проверить, наблюдалось ли оно в нужный момент, и лишь затем обсуждать причины с провайдером.

Руководство предназначено для администратора VPS с Ubuntu 24.04 LTS и утилитой vmstat из procps-ng 4.0.4. Нужен разрешённый терминальный доступ в гостевую ОС и чтение системной статистики procfs. Обычно для приведённых команд достаточно обычного пользователя. Отказ доступа не следует обходить повышением прав. Для контейнера внутри VPS область видимой статистики нужно выяснять отдельно: её нельзя автоматически считать показателями именно этого контейнера.

Гипервизор распределяет процессорное время между виртуальными машинами. В документации Linux для KVM steal time описывает время, когда виртуальный процессор не выполнялся; его собственный простой в этот показатель не включается. В выводе vmstat нужный столбец называется st и выражен в процентах общего процессорного времени. Это не процент, который использует конкретный процесс магазина.

Из гостевой машины можно увидеть след ожидания, но нельзя по нему назвать соседнюю виртуальную машину или доказать нарушение условий тарифа. Для такого вывода нужны сведения со стороны хоста и правила выделения ресурсов. Значение зависит и от поддержки учёта в связке гипервизора и гостевой ОС. Нулевой результат в короткой выборке не подтверждает отсутствие всех ограничений производительности.

1. Проверьте установленную утилиту:

   vmstat --version

   Для описанного варианта ожидается семейство procps-ng версии 4.0.4. Если команда отсутствует или вывод относится к другой реализации, остановитесь и проверьте документацию среды. Установка пакетов в эту инструкцию не входит.

2. Запишите время наблюдения и часовой пояс, затем получите шесть отчётов с секундным интервалом:

   vmstat 1 6

   Первый отчёт по CPU усредняет время с загрузки системы. Для текущего эпизода смотрите следующие пять строк. Команда завершится сама; вывод не является записью длительного инцидента. Это ограниченная выборка чтения, а не нагрузочный тест. Не запускайте множество таких наблюдений одновременно.

3. Найдите st по заголовку и сохраните строки вместе с остальными столбцами. После завершения эпизода повторите ту же короткую выборку в спокойный период. Отметьте, совпали ли ненулевые значения с задержкой конкретного действия магазина. Сравнивать нужно наблюдения с известным временем, а не скриншоты разных дней без контекста.

Команды сверены с официальным руководством Ubuntu Noble 27 сентября 2026 года и выполнены в изолированной среде Ubuntu 24.04.3 с procps-ng 4.0.4. Получены шесть строк; во всех st равнялся нулю. Проверены запуск и формат вывода. Конкуренция за CPU на реальном узле виртуализации не воспроизводилась, поэтому этот запуск не проверяет поведение VPS под такой нагрузкой.

Соседние столбцы помогают выбрать направление: us отражает выполнение пользовательского кода, sy — кода ядра, id — простой. Значение wa связано с ожиданием ввода-вывода. Для wa документация ядра отдельно описывает ограничения учёта, поэтому его нельзя считать точным измерением задержки диска. Сохранить полный заголовок полезнее, чем передавать одну цифру без названия показателя.

Условный пример: после первой строки в пяти секундных отчётах st последовательно равен 0, 12, 18, 0 и 0. Среднее этих пяти равно 6%. Но такой средний показатель скрывает два коротких всплеска. Если медленный запрос пришёлся именно на них, появляется гипотеза о влиянии ожидания CPU. Это учебные числа, а не результат нашего запуска и не допустимый порог для любого VPS.

Из этих 6% нельзя вывести, что каждый запрос магазина выполнялся на 6% дольше. Задачи различаются по потребности в CPU, могут ждать базу или внешний сервис; усреднение по процессорам и времени теряет детали. Для связи с пользовательским симптомом нужны интервалы запроса и наблюдения. Даже их совпадение поддерживает гипотезу, но само по себе ещё не доказывает единственную причину.

Если преимущественно растёт работа пользовательского кода при низком st, следующий вопрос — какие процессы и операции занимают CPU. Если повторяется заметное ожидание виртуального процессора, полезны сведения провайдера о выделении времени на хосте. Оба явления могут существовать одновременно. Покупка дополнительных виртуальных процессоров без понимания ограничения не даёт гарантии, что задержка исчезнет.

В обращение достаточно включить идентификатор своей VPS, время и часовой пояс, версию ОС и утилиты, несколько строк с заголовком, длительность симптома и обезличенное описание действия магазина. Попросите сопоставить этот интервал с ожиданием на хосте и действующими ограничениями процессорного ресурса. Полная база магазина, пароли и журналы с данными покупателей для первичного разбора не нужны.

Если для дальнейшей проверки предлагают перезагрузку, миграцию или изменение тарифа, это уже отдельная операция: заранее согласуйте влияние на доступность, сохранность данных и проверку результата. Сам показатель st не предписывает ни одного из этих действий. Полезный итог короткого наблюдения — установить, было ли зафиксировано ожидание виртуального процессора в момент проблемы, и передать следующий вопрос тому, у кого есть данные хоста.

During catalog import, the store responds slowly, yet no process inside the VPS appears particularly busy. The virtual machine has another possible source of delay: its virtual processor is ready to work, but the physical processor is not yet available. In Linux, part of this wait is reflected as steal time. First, check whether it occurred at the right moment, and only then discuss the causes with the provider.

This guide is intended for a VPS administrator running Ubuntu 24.04 LTS and the vmstat utility from procps-ng 4.0.4. Authorized terminal access to the guest OS and read access to procfs system statistics are required. Typically, standard user privileges are sufficient for the commands provided. Access denial must not be bypassed by escalating privileges. For a container running inside a VPS, the scope of visible statistics must be determined separately; it cannot be automatically assumed to represent metrics for that specific container.

The hypervisor distributes CPU time among virtual machines. In Linux documentation for KVM, steal time describes the period when a virtual processor was not executing; its own idle time is not included in this metric. In the vmstat output, the relevant column is named st and is expressed as a percentage of total CPU time. This is not the percentage used by a specific store process.

From a guest machine, you can see the wait trace, but you cannot identify the neighboring virtual machine or prove a tariff violation based on it. Such conclusions require data from the host side and resource allocation rules. The result also depends on accounting support in the hypervisor and guest OS combination. A zero result in a short sample does not confirm the absence of all performance limitations.

1. Check the installed utility:

   vmstat --version

   For the described scenario, the procps-ng version 4.0.4 family is expected. If the command is missing or the output refers to a different implementation, stop and check the environment documentation. Installing packages is not part of this instruction.

2. Record the observation time and time zone, then obtain six reports at one-second intervals:

   vmstat 1 6

   The first CPU report averages time since system boot. For the current episode, view the following five lines. The command will terminate automatically; the output is not a record of a long-term incident. This is a limited read sample, not a load test. Do not run multiple such observations simultaneously.

3. Find st by title and save the rows along with the remaining columns. After the episode completes, repeat the same short selection during a quiet period. Note whether non-zero values coincided with the delay specific to the store action. You must compare observations against known times, not screenshots from different days without context.

The teams aligned with the official Ubuntu Noble guidelines as of September 27, 2026, and executed the tests in an isolated Ubuntu 24.04.3 environment with procps-ng 4.0.4. Six rows were obtained; in all st the value was zero. Startup and output format were verified. CPU contention on a real virtualization node was not reproduced, so this run does not test VPS behavior under such load.

Adjacent columns help determine the direction: us reflects user code execution, sy reflects kernel code, and id reflects idle time. The value wa relates to I/O wait. For wa, kernel documentation separately describes accounting limitations, so it cannot be considered an accurate measure of disk latency. Keeping the full header is more useful than passing a single number without the metric name.

Hypothetical example: after the first line in five-second reports, st sequentially equals 0, 12, 18, 0, and 0. The average of these five is 6%. However, such an average hides two short spikes. If a slow request coincided with those spikes, a hypothesis about CPU wait influence arises. These are training numbers, not results from our run, nor an acceptable threshold for any VPS.

From these 6%, one cannot conclude that every store request took 6% longer. Tasks differ in CPU requirements, may wait for a database or external service; averaging across processors and time loses details. To link to a user symptom, request and observation intervals are needed. Even their coincidence supports a hypothesis but does not by itself prove a single cause.

If user code activity grows predominantly at a low st, the next question is which processes and operations are consuming CPU. If noticeable virtual CPU wait time recurs, provider data on time allocation on the host is useful. Both phenomena can coexist. Purchasing additional virtual CPUs without understanding the bottleneck does not guarantee that latency will disappear.

It is sufficient to include your VPS identifier, time, time zone, OS version, and utilities, a few lines with a header, the symptom duration, and an anonymized description of the store action. Request that this interval be matched against host wait times and existing CPU resource limits. A full store database, passwords, and logs containing customer data are not needed for initial analysis.

If further checks involve a reboot, migration, or tariff change, this is a separate operation: agree in advance on the impact on availability, data integrity, and result verification. The st indicator itself does not prescribe any of these actions. A useful outcome of short-term observation is to determine whether virtual CPU wait time was recorded during the issue and pass the next question to whoever has host data.