ESXi 5.x CPU scheduler

1© Copyright 2011 EMC Corporation. All rights reserved.
VMware ESXi 5.1
Планировщик
процессора
Антон Жбанков
http://blog.vadmin.ru

Терминология
• Socket
• pCPU
– Ядро
– Логический процессор при HT
• Cache
• LLC – Last level cache
– Последний уровень кэша перед обращением в память
• vCPU (World)
• NUMA

Состояния world

Что планировать?
• ВМ состоит из одного или несколько world
– 1 world на каждый vCPU
– а также существуют world, обслуживающие мышь, клавиатуру и
legacy I/O устройства
– Теоретически для 1vCPU 100+% возможно, но маловероятно
• VMkernel management worlds
• Прерывания и контексты ввода-вывода (IO)

Что планировать?
• Планировщик вызывается при истечении кванта
времени, выделенного world
– 50 мс по умолчанию
– Либо по переходу world в состояние Wait
• Ищется следующий world в состоянии Ready в
локальной или удаленной очереди
• Если нет ни одного в состоянии Ready, то планируется
world в состоянии Idle
• Также планировщик вызывается при переходе из Wait в
Ready (напр. по прерыванию или сигналу)

Алгоритм пропорциональных долей
• Алгоритм выбора world для исполнения
– На основе Share, Limit, Reserve
• World может не полностью потребить выделенные
ресурсы из-за фрагментации
– Становится высокого приоритета и попадает в очередь
• Критическим становится биллинг – кто сколько потребил

Shares

Reserve

Limit

Приоритет
• UNIX
– Приоритет произвольно назначается пользователем
– Имеет числовое значение
– При сравнении имеет значение только у кого приоритет больше
• ESXi
– Приоритет постоянно перевычисляется
– На основе выделенных и реально потребленных ресурсов
– Пользователь не может назначить приоритет world напрямую,
только через Share, Limit и Reserve

Co-Scheduling
• Для vSMP (vCPU > 1) все vCPU world необходимо
исполнять одновременно
• При непараллельном исполнии резко возрастает
задержка при межпроцессном взаимодействии
• Как итог – перерасход ресурсов
• Skew – числовой показатель разности между прогрессом
vCPU одной машины

Strict Co-Scheduling (ESX 2.x)
• При превышении порогового значения Skew машина
целиком останавливалась
• Исполнение возобновлялось только при наличии
свободных таймслотов для всех vCPU
• Idle vCPU всегда считается равным самому быстрому
vCPU
• 4x vCPU ВМ могла не попасть в очередь при наличии 3х
свободных pCPU
• Итог – фрагментация процессора, низкая
производительность

Strict Co-Scheduling (ESX 2.x)
Всего 61%
pCPU1 pCPU2 pCPU3 pCPU4

Relaxed Co-Scheduling
• Каждый vCPU измеряет собственный прогресс
• При превышении порогового значения Skew
лидирующий vCPU переходит в состоянии Co-Stop
• По мере снижения значения Skew и при наличии
свободного pCPU world может перейти из состояния Co-
Stop в Co-Start
• Значительное снижение фрагментации, 4x vCPU
машина может работать при всего 1 свободном pCPU

Relaxed Co-Scheduling
pCPU1 pCPU2 pCPU3 pCPU4
Уже 73%

Балансировка нагрузки
• Миграция world
– Pull инициируется pCPU при переходе в Idle
– Push инициируется vCPU при переходе в Ready
• Стоимость миграции
– Снова прогревать кэш – очень сильно влияет на отдельные
виды нагрузки
• Goodness of Migration
– Для каждой пары vCPU-pCPU вычисляется значение пользы
миграции (Goodness) и осуществляется миграция с
максимальной пользой

Польза миграции
• CPU load
– При высокой загрузке pCPU источника и низкой pCPU
назначения польза считается высокой
• Last-Level Cache
– В первую очередь рассматриваются pCPU с общим LLC,
поскольку обращение к памяти на порядок медленнее
– В особенности важно для vSMP машин
• Hyper-Threading
– Польза миграции повышается, если соседний логический
процессор HT пары менее загружен

• Топологическая дистанция
– Для pCPU-pCPU расчитывается топологическая дистанция
– HT пара делит общий L1 кэш, что делает ТД меньше, чем для
двух pCPU с общим LLC
– pCPU без общего LLC имеют еще большую ТД
• Стоимость миграции против пользы миграции
– Прогрев кэша расходует ресурсы
– Может получиться, что оставить как есть дешевле, чем
мигрировать

• Co-scheduling
– Планировщик максимально избегает размещения двух vCPU
одной ВМ на одном и том же pCPU во избежание разбега
– Польза считается значительно выше, если на pCPU назначения
не размещен другой vCPU той же ВМ
• Коммуникация между контекстами
– Планировщик оценивает уровень межпроцессного
взаимодействия
– vCPU с высоким уровнем общения с большей вероятностью
будут размещены «поблизости», чтобы увеличить попадания в
кэш

Hyper-Threading
• HT процессор = 2 потока на ядро
– Производительность каждого потока зависит от второго
– Поток со свободным 2м дает больше вычислительной
мощности, чем если оба потока заняты
• Биллинг для HT процессоров отличается
– Принцип честности
• Последние поколения процессоров лучше справляются
– ESXi 5.x с большей вероятностью выбирает HT поток, чем
ранее
– Полностью свободное ядро все еще имеет больший приоритет

NUMA
• NUMA – Non Uniform Memory Access
• NUMA узел
– Процессор (Socket)
– Его память (локальная)
• Стоимость доступа к чужой памяти выше
– Максимально оставаться в рамках узла
– vCPU размещаются только в NUMA home (домашнем узле)
– Смена NUMA home
• Миграция памяти – дело дорогое
– Осуществляется только если ВМ остается в новом узле долго

NUMA миграция
• Для кратковременной балансировки CPU
• Для повышения локальности памяти
– Если память еще не была мигрирована, то имеет смысл
мигрировать ВМ назад
• ВМ с частой коммуникацией между ними
– /Numa/LocalityWeightActionAffinity 0
• Для обеспечения принципа честности в долгой
перспективе
– /Numa/LTermFairnessInterval 0

Wide NUMA
• Широкая NUMA машина
– Количество vCPU > количества pCPU в NUMA узле
• Широкая машина разбивается на несколько клиентов
– Каждый клиент должен помещаться в узле
• HT
– HT удваивает количество логических ядер, поэтому 8 vCPU ВМ
на 4х ядерном процессоре с HT будет попадать в размер NUMA
узла
– numa.vcpu.preferHT TRUE

Память для Wide NUMA
• Равномерно чередуется для широких машин в 4.x
– NUMA скрывается от гостевой ОС
• vSphere 5.x vNUMA
– NUMA презентуется гостевой ОС

Память для Wide NUMA

vNUMA – SPEC OMP

Проблемы vNUMA
• В физическом мире топология NUMA неизменна
• В виртуальном меняется
– vMotion на хост с иной топологией
– Не все приложения понимают изменение топологии
• Автоконфигурация
– numa.autosize TRUE
– numa.autosize.once FALSE
– Требуется перезагрузка

Несоответствие NUMA и vNUMA
• vNUMA < NUMA
– vNUMA целиком помещается в узел. Никаких проблем
• vNUMA = x*NUMA
– vNUMA разбивается на x NUMA узлов и память чередуется
между ними
• vNUMA != x*NUMA
– vNUMA все еще сохраняется для гостевой ОС
– NUMA клиенты определяются в зависимости от размера NUMA
узла, а не vNUMA. Память чередуется между ними
– По факту vNUMA просто не работает

Выводы
• Избегайте ресурсов (vCPU) на всякий случай
• Узнайте свою инфраструктуру
– NUMA
– Процессорная архитектура
• Большие машины требуют планирования
• Избегайте менять значения расширенных параметров
– Значений по умолчанию достаточно в 99% случаев
• Сначала подумал – потом сделал!
– А не наоборот!

Контакты – Антон Жбанков
• EMC Senior SE /
Software Defined Specialist
• anton.zhbankov@emc.com
• anton@vadmin.ru
• http://blog.vadmin.ru
• @antonvirtual
• + Facebook, LinkedIn etc…

THANK YOU

ESXi 5.x CPU scheduler

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie ESXi 5.x CPU scheduler

Ähnlich wie ESXi 5.x CPU scheduler (20)

ESXi 5.x CPU scheduler