Назад в блог

Крадем ли мы у вас? Понимание CPU steal time в облаке

Крадем ли мы у вас? Понимание CPU steal time в облаке

Клиенты часто спрашивают о CPU steal time. Особенно те, кто интенсивно использует процессоры и для кого это ключевой критерий производительности. Существует довольно много различий в настройке и поведении процессоров и ядер между физическими и виртуальными средами. Даже между облачными провайдерами существуют различия в настройках, которые затрудняют прямое сравнение. По этой причине мы посчитали полезным предоставить краткий обзор нашей настройки и логики распределения процессоров для клиентов, а также объяснить наиболее распространенные источники CPU steal time.

Итак, во-первых, для тех, кто не знаком с этой концепцией: CPU steal time — это время, в течение которого ваш виртуальный процессор внутри облачного сервера должен ждать реальный физический процессор, пока гипервизор занят его использованием для других задач (например, для других виртуальных машин/облачных серверов). Это отличная статья о CPU steal time, которую определенно стоит прочитать.

Немного информации о настройке наших процессоров

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

В сочетании с этим мы используем Control Groups (сокращенно cgroups), чтобы гарантировать достаточное количество процессорного времени для каждого из облачных серверов в соответствии с ресурсами, которые вы установили через размер сервера. В конечном итоге планировщик решает, что делать с оставшимися ресурсами и cgroups. Также стоит отметить, что мы резервируем набор определенных ядер, которые находятся вне диапазона распределения для вычислительных нагрузок клиентов. Мы используем эти ядра для работы операционной системы физического хоста. В частности, мы резервируем дополнительные ядра для обработки сетевых операций и операций хранения данных. Все это направлено на повышение стабильности работы машины в целом. Кроме того, это помогает обеспечивать надежный уровень производительности в течение долгого времени независимо от нагрузки других клиентов.

Источники CPU steal time в виртуализированной среде

В отличие от физической среды, существует множество источников и ситуаций, в которых вы можете столкнуться с CPU steal time. Это связано с тем, что в многопользовательской виртуализированной среде все устроено сложнее. Не все из них действительно представляют собой ситуацию, когда вы не получаете положенного процессорного времени; на самом деле во многих случаях вы часто можете поглощать свободные такты процессора сверх выделенного вам объема, но это не та ситуация, когда вы увидите CPU steal time. Три наиболее распространенные ситуации подробно описаны ниже.

Ваш облачный сервер перегружен
Это случается! Каждый хочет использовать оплаченные ресурсы как можно ближе к полной мощности, однако если выделенного процессора для вашего виртуального облачного сервера недостаточно для обработки рабочей нагрузки, вы можете увидеть CPU steal time, так как задачи накапливаются и выстраиваются в очередь внутри виртуального процессора. Если это является первопричиной CPU steal time, то решением будет изменение размера облачного сервера. Если это временная перегрузка, вы можете спокойно оставить все как есть. Вы увидите, что CPU steal time исчезнет, когда ваша нагрузка снизится.

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

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

Если физическое ядро имеет частоту 2.6GHz, но ваша VM имеет частоту 4GHz и два ядра, каждое виртуальное ядро будет иметь частоту 2GHz. Таким образом, вы всегда будете видеть steal time. На самом деле это связано с тем, что вы получаете пропорциональную часть от общего ядра, а не полный размер, из-за меньшего размера виртуального ядра. Поэтому вам всегда следует корректировать любые расчеты CPU steal time, чтобы учесть меньший размер виртуального ядра, если вы действительно его используете. Чтобы избежать этого, вы можете использовать полный размер ядра для каждого ядра. Вы можете сделать это, увеличив размер виртуального ядра до полного размера ядра CPU (например, Intel v4 2.6GHz).

Заключение

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

Приятной работы!

Роберт

 

author

Роберт Дженкин

Автор · CloudSigma

Preslav Dobrev — креативный дизайнер в CloudSigma, сосредоточенный на формировании последовательного корпоративного образа с помощью традиционных и инновационных маркетинговых каналов. Он умело сочетает художественное видение со стратегическим маркетингом, создавая убедительные истории бренда.

Комментарии

Комментариев пока нет. Будьте первым.