Иногда виртуальный сервер ведет себя довольно странно. Процессор вроде бы не занят на сто процентов, памяти хватает, на сайте ничего не меняли, но страницы внезапно начинают открываться медленнее. Через некоторое время все приходит в норму, а вечером проблема возвращается.
В такой ситуации легко начать искать тяжелый PHP-скрипт, обвинять базу данных или увеличивать количество процессорных ядер. Но у VPS есть еще один источник задержек, которого вообще нет у обычного физического сервера в таком виде. Виртуальная машина может быть готова выполнять работу, но не получить физический процессор в нужный момент.
Linux умеет учитывать такое ожидание. Показатель называется CPU Steal или steal time, а в знакомой утилите top его можно увидеть в поле %st.
Само слово steal звучит немного драматично. Никто буквально не крадет процессор вашего VPS. Это показатель того, как распределяется физическое процессорное время между виртуальными машинами.
Откуда вообще берется CPU Steal
Чтобы понять steal time, полезно на минуту забыть рекламную страницу VPS и представить физический сервер, стоящий в дата-центре.
У него есть настоящие процессоры с физическими ядрами. На этом сервере провайдер запускает несколько виртуальных машин. Каждая из них получает виртуальные процессоры, которые обычно обозначают как vCPU.
Изнутри VPS они выглядят почти как обычные процессоры. Linux распределяет между ними процессы сайта, базы данных, веб-сервера и других программ.
Но vCPU все равно должна в какой-то момент получить доступ к настоящему процессору физического сервера. Этим распределением занимается слой виртуализации.
Представим, что ваш VPS хочет выполнить PHP-код. Задача готова, операционная система готова ее запустить, но физическое ядро в этот момент обслуживает другую виртуальную машину. Вашей приходится ждать.
Вот это потерянное для виртуальной машины время и отражается в steal time.
В документации Red Hat определение сформулировано довольно точно: это процессорное время, которое требовалось гостевой виртуальной машине, но не было предоставлено хостом, потому что ресурс был выделен в другое место.
Чем CPU Steal отличается от обычной загрузки процессора
Разница принципиальная.
Если ваш PHP-процесс использует CPU, сервер действительно выполняет вашу работу. Если процессор простаивает, Linux может показать значительную долю idle. Если система ждет завершения дисковых операций, появляется другой показатель.
Steal означает иную ситуацию: работа была готова выполняться, но сама виртуальная машина некоторое время не получила физический CPU.
Поэтому увеличение %st нельзя автоматически трактовать как тяжелый сайт.
Ваш код способен косвенно влиять на ситуацию тем, сколько процессорного времени требуется VPS, но источник steal находится уровнем выше самой виртуальной машины.
Именно этим показатель интересен при диагностике. Он позволяет увидеть часть того, что происходит за пределами вашей гостевой Linux-системы.
Почему это вообще возможно на VPS
Виртуализация как раз и позволяет эффективно делить мощный физический сервер между несколькими клиентами.
Нет ничего неправильного в том, что разные VPS используют общие физические процессоры. Более того, без такого распределения виртуальные серверы потеряли бы значительную часть своей экономической привлекательности.
Проблема появляется тогда, когда за физический CPU одновременно начинает конкурировать слишком много активной работы.
Например, днем несколько виртуальных машин почти ничего не делают. Вечером на одной запускается тяжелая обработка данных, на другой начинается резервное копирование, а третья получает всплеск посетителей. Гипервизору приходится распределять физический процессор между большим количеством желающих его использовать.
В результате производительность вашего VPS может меняться, хотя непосредственно внутри него конфигурация осталась прежней.
Как посмотреть CPU Steal на своем VPS
Для первоначальной проверки не нужно устанавливать сложную систему мониторинга. Если у вас есть SSH-доступ к Linux-серверу, можно начать с обычного top.
topВ строке со статистикой CPU среди нескольких значений обычно присутствует поле st. В зависимости от версии и оформления утилиты оно может отображаться как %st.
Это и есть steal time.
Если значение равно нулю или близко к нему, в момент измерения заметного ожидания физического CPU со стороны виртуальной машины не наблюдается.
Если %st растет одновременно с замедлением сервера, ситуация становится интереснее.
Одного снимка top недостаточно
Здесь легко совершить ошибку. Пользователь открывает top, замечает какое-то ненулевое значение и сразу пишет провайдеру, что физический сервер перегружен.
Так делать не стоит.
Нагрузка в компьютерных системах постоянно меняется. Кратковременное значение само по себе почти ничего не доказывает. Гораздо полезнее посмотреть, повторяется ли явление и совпадает ли оно с реальными проблемами производительности.
Например, сайт каждый вечер начинает отвечать медленнее. В это же время %st заметно повышается и остается таким не несколько секунд, а наблюдается регулярно. Утром сайт снова быстрый, а steal практически исчезает.
Такое наблюдение намного полезнее одного случайного измерения.
Для диагностики можно использовать и vmstat:
vmstat 1Последний столбец CPU-статистики обычно обозначается st. Команда позволяет наблюдать изменение показателей с заданным интервалом, а не смотреть на единственный момент времени.
Сам Linux хранит соответствующую статистику в /proc/stat, а системные утилиты уже представляют ее человеку в более удобном виде.
Лучше смотреть историю, а не ловить тормоза вручную
Самая неприятная особенность плавающих проблем заключается в том, что они исчезают именно тогда, когда администратор подключается к серверу.
Владелец сайта пишет: в 20:30 все тормозило. Администратор заходит в 21:10, запускает top и видит идеальный сервер.
Поэтому для постоянно работающего проекта полезен мониторинг, который сохраняет историю загрузки CPU, памяти, дисковой активности и других показателей.
Тогда можно вернуться к нужному моменту и сравнить несколько метрик одновременно.
Это важно еще и потому, что медленный сайт не обязательно означает CPU Steal. Внешне совершенно разные проблемы могут выглядеть одинаково: пользователь нажал ссылку и слишком долго ждет страницу.
Как понять, что проблема действительно связана с VPS
Высокий steal time является важной подсказкой, но превращать его в универсальный диагноз тоже нельзя.
Сначала нужно понять, что происходило с самим сервером.
Посмотрите на обычное использование CPU. Проверьте оперативную память. Обратите внимание на дисковую активность. Посмотрите процессы, которые работали в момент замедления. Если проблема связана с конкретным сайтом, полезно проверить его журналы и время ответа приложения.
Причина может оказаться совершенно локальной.
Например, база данных выполняет тяжелый запрос. PHP-процессы заняли доступные воркеры. На сервере закончилась память. Выполняется резервное копирование. Диск перегружен операциями ввода-вывода.
Во всех этих случаях смена VPS-провайдера может ничего не исправить.
Не существует магического процента для всех серверов
Очень хочется получить простое правило: до определенного процента все хорошо, после него хостинг плохой.
На практике такой универсальной границы нет.
Кратковременный всплеск и постоянное ожидание имеют совершенно разное значение. Важна чувствительность приложения к задержкам, продолжительность проблемы, частота ее появления и фактическое влияние на работу сервиса.
Если небольшой %st иногда появляется на графике, а сайт работает быстро и стабильно, искать новый VPS только из-за красивой метрики бессмысленно.
Другая ситуация возникает, когда steal регулярно становится заметной частью процессорного времени именно во время деградации производительности.
Тогда у администратора появляется основание изучать проблему глубже.
Высокий CPU Steal не доказывает оверселлинг
Это особенно важный момент.
Steal time действительно связан с конкуренцией за физический процессор. Но по одному этому показателю нельзя достоверно установить коммерческую политику провайдера и заявить, что он продал клиентам слишком много ресурсов.
Конкуренция может возникать по разным причинам. Например, несколько виртуальных машин на узле одновременно получили необычно высокую нагрузку.
Постоянно высокий steal может быть симптомом чрезмерной загрузки физического хоста, но это не инструмент, который раскрывает точное количество соседей, их тарифы и коэффициент переподписки ресурсов.
Поэтому формулировка для поддержки должна звучать не как обвинение, а как техническое наблюдение.
Гораздо полезнее сообщить время возникновения проблемы, приложить показатели и описать влияние на работу сервера.
Что делать, если steal time регулярно высокий
Первое желание понятно: перезагрузить VPS. Иногда после перезагрузки действительно кажется, что все стало быстрее. Но если причина находится на физическом хосте, перезапуск гостевой системы сам по себе ее не устраняет.
Лучше собрать данные.
Зафиксируйте время, когда сервер тормозит. Посмотрите %st в top или vmstat. Проверьте обычную загрузку CPU, память и дисковую активность. Если есть мониторинг, сохраните графики за проблемный период.
После этого можно обращаться в поддержку.
Провайдер видит физический узел гораздо лучше клиента VPS. У него есть информация о загрузке хоста, работе гипервизора и других обстоятельствах, недоступных изнутри виртуальной машины.
Поддержке нужны наблюдения, а не предположения
Сообщение сервер тормозит дает специалисту мало информации.
Намного полезнее написать, что проблема наблюдалась, например, несколько раз за последние дни в определенные периоды, а во время замедления увеличивался CPU steal. Если одновременно есть данные о времени ответа сайта или выполнении конкретной задачи, их тоже стоит приложить.
Так поддержке проще сопоставить жалобу с состоянием физического сервера.
В зависимости от инфраструктуры и причины провайдер может проверить узел, изменить распределение ресурсов или перенести виртуальную машину на другой физический сервер.
Конкретное решение уже зависит от платформы хостера.
Больше vCPU не обязательно решат проблему
Еще одна заманчиво простая идея заключается в переходе на тариф с большим количеством виртуальных процессоров.
Иногда это действительно необходимо. Если приложение объективно упирается в доступную вычислительную мощность, дополнительные vCPU способны помочь.
Но steal time говорит о другом явлении: виртуальный CPU не получил физическое процессорное время тогда, когда хотел выполнять работу.
Поэтому сначала нужно выяснить причину, а потом покупать ресурсы.
Если проблема заключается в перегруженном физическом узле, более дорогой тариф на той же инфраструктуре не обязательно окажется тем лечением, которое вы ожидали.
И наоборот, если steal практически отсутствует, а ваши процессоры постоянно полностью заняты собственными задачами, тогда увеличение вычислительных ресурсов выглядит гораздо логичнее.
CPU Steal полезен именно как часть диагностики
Самая большая ценность steal time не в том, что он позволяет оценить хостинг одним числом. Такой возможности он как раз не дает.
Ценность в другом: показатель помогает отделить работу внутри виртуальной машины от конкуренции за процессорный ресурс на уровне виртуализации.
Это особенно полезно при плавающих проблемах.
Если сайт тормозит, а администратор видит высокую собственную загрузку CPU, он ищет тяжелые процессы и оптимизирует приложение. Если растет ожидание диска, исследует хранилище и операции ввода-вывода. Если заканчивается память, разбирается с ее потреблением.
А если одновременно с проблемой регулярно растет steal, появляется еще одно направление проверки: доступность физического процессорного времени для самой виртуальной машины.
Именно поэтому владельцу VPS полезно хотя бы знать, что означает маленькое поле st в top.
Оно не позволяет увидеть всех соседей по физическому серверу и не доказывает, что провайдер экономит на оборудовании. Но оно показывает важную вещь: часть времени ваш виртуальный процессор был готов работать, однако физический CPU ему не достался.
Если такое происходит редко и никак не отражается на сайте, беспокоиться не о чем. Если ситуация повторяется, совпадает с заметными тормозами и подтверждается историей мониторинга, проблему уже стоит обсуждать с хостинг-провайдером.
А при выборе нового VPS полезно помнить более общий принцип: количество vCPU в тарифе говорит о конфигурации виртуальной машины, но реальная производительность зависит еще и от того, как устроена и загружена физическая инфраструктура, на которой эти виртуальные процессоры работают.
