Главная Virtualization, Новое ESX CPU scheduler deepdive. Multicore-Aware Load Balancing
  • ESX CPU scheduler deepdive. Multicore-Aware Load Balancing

    Архитектура CMP (chip mutiprocessor) привносит новые проблемы алгоритмам балансировки нагрузки ввиду различных вариантов исполнения кэша на чипе. Предыдущие поколения процессоров обычно были с частным L2 кэшем, а более новые имеют общий как L3, так и L2 кэш. Также, количество ядер, использующих общий кэш варьируется от двух до четырех и более. Кэш последнего уровня (LLC — last level cache) — кэш, после которого идет обращение к оперативной памяти. Поскольку задержка при доступе к LLC и RAM различается как минимум на порядок, поддержание высокого уровня cache-hit для LLC становится жизненно необходимым для высокой производительности.
    Балансировка нагрузки достигается миграцией vCPU, но после миграции vCPU должен «разогреть» кэш. И в связи с этим реальная стоимость миграции очень сильно зависит от того, требует ли разогрев кэша доступа к оперативной памяти, который не может быть удовлетворен за счет LLC. Иными словами, миграция в пределах LLC значительно дешевле, чем между LLC. Ранее эта внутричиповая топология игнорировалась планировщиком и стоимость миграции считалась одинаковой и фиксированной. Тем не менее, результат был удовлетворительным, поскольку механизм приоритезации миграции между ячейками планировщика (scheduler cell) приводил к высокому уровню между-LLC миграций — ячейка в большинстве случаев равняется одному, как максимум двум LLC.
    В ESX4 понятие ячейки планировщика более не используется, а следовательно между-LLC миграции более не приоритезируются. Таким образом механизм балансировки нагрузки занчительно улучшился, поскольку миграция внутри LLC предпочтительнее миграции между LLC. Когда планировщик выбирает pCPU для миграции, локальный процессор, разделяющий LLC, всегда предпочтительнее удаленного, не разделяющего тот же LLC. Тем не менее, миграция на удаленный pCPU все еще возможна, если выбор локального pCPU не может решить проблему балансировки нагрузки.

    CPU Load-Based Migration Throttling

    В ESX4 vCPU, привносящий значительную нагрузку на текущий pCPU не будет мигрировать, вместо этого планировщик будет в первую очередь мигрировать vCPU с низкой нагрузкой. Данный механизм позволяет снизить количество миграций из-за мнимого дисбаланса. В низконагруженных средах легко может оказаться, что лишь несколько процессоров заняты, поскольку не хватает vCPU, способных нагрузить систему. Попытка выровнять нагрузку в данном случае приведет к ненужным миграциям и снизит производительность.
    Например, один vCPU дает 95% нагрузки на pCPU (PA), в то время как остальные pCPU простаивают. Если другой простаивающий pCPU (PB) инициирует миграцию vCPU, то через некоторое время оригинальный pCPU (PA) станет проистаивающим и инициирует миграцию назад. Таким образом приоритезация миграции по нагрузке избавляет нас от этого пинг-понга. Высокая нагрузка на pCPU также означает и высокий вклад в кэш, поскольку у vCPU достаточно времени для разогрева кэша и соотв. высокой доли использования кэша. Это, конечно, не идеальная следственная связь, но вполне разумное предположение. Приоритезация миграций в зависимости от нагрузки на процессор может рассматриваться как необходимое условие для приоритезации миграций на основе рабочего набора в кэше. Точное определение размера рабочего набора в кэше и использование этого для приоритезации миграций — то, что возможно, будет реализовано в следующих версиях гипервизора.
    Миграция vCPU начинает приоритезироваться по нагрузке только при условии, что vCPU имеет действительно большую долю в нагрузке на текущий pCPU. Пороговое значение установлено достаточно большим, чтобы разрешать миграции, действительно улучшающие общую производительность. По мере роста нагрузки на систему в целом приоритезация становится все менее вероятной ввиду того, что вклад каждого vCPU в процентном соотношении снижается. Проблема мнимого дисбаланса актуальна только для недозагруженных систем.

    Impact on Processor Caching

    В ESX4 vCPU виртуальной машины может быть размещен на любом pCPU, поскольку ячейки планировщика ушли в небытие. При работе алгоритма балансировки на основе нагрузки на LLC есть тенденция к разбеганию vCPU одной виртуальной машины по разным LLC. Тем не менее, все они остаются в пределах одного узла NUMA, если машина управляется планировщиком NUMA. Большее количество агрегированного кэша и ширины канала доступа к памяти улучшают производительность для большинства видов нагрузок. Однако нагрузки с интенсивной межпроцессной комуникацией могут страдать от снижения производительности при размещении по разным LLC.
    Например, рассмотрим параллельное приложение с малым рабочим набором кэша, но очень частым взаимодействием производитель-потребитель взаимодействием между нитями. Также предполжим, что эти нити распределены по различным vCPU. Если хост недозагружен, то скорее всего vCPU были распределены между различными LLC. Таким образом взаимодействие между нитями приводит к большому количеству cache-miss и общему снижению производительности. Если бы рабочий набор был больше, чем LLC, то политика по-умолчанию улучшила бы производительность.
    Относительный эффект большего агрегированного кэша в значительной степени зависит от приложения. Также как и с предыдущим механизмом, динамическое определение типа приложения и изменение политики планировщика на лету бросает новые выовы и будет составлять основу будущей работы. На сегодняшний день можно вручную принудительно задать политику консолидирования кэша.

    vSMP Consolidation

    Если есть уверенность, что приложение в виртуальной машине получит выигрыш от разделяемого кэша, а не от большего его объема, этот эффект можно достичь при консолидации vSMP. Консолидация vSMP приведет к приоритезации выбора pCPU в пределах LLC для vCPU данной ВМ. Тем не менее, иногда это может и не случиться, в зависимости от доступности pCPU.
    Для включения консолидации vSMP необходимо изменить следующий расширенный параметр для ВМ:

    sched.cpu.vsmpConsolidate = true

    Inter-VM Cache Affinity

    В ситуации, когда две ВМ на одном и том же хосте интенсивно обмениваются информацией, возможно увеличение производительности при работе в пределах одного кэша. Эта ситуация применима только к разделению кэша между ВМ, консолидация vSMP применяется для консолидации кэша внутри одной машины. Как следствие, vSMP работает только для многопроцессорных машин, а в данном случае возможно консолидировать и однопроцессорные машины. Планировщик ESX в автоматическом режиме определяет «разговорчивые» машины на хосте и пытается разместить их в пределах LLC. Тем не менее, этого может и не случиться, в зависимости от нагрузки на хост.

    Aggressive Hyperthreading Support

    Балансировка нагрузки для архитектуры с многопоточными процессорами (hyperthreading) — тема для отдельного поста. Политика миграции по умолчанию выбирает полностью незагруженное ядро (оба потока свободны), предпочитая его частично загруженному — тому, у которого загружен один поток. Посколько оба аппаратных потока конкурируют за один процессор, использование частично загруженного ядра приводит к ухудшению производительности, по сравнению с полностью свободным ядром. Как результат, наблюдается асимметрия в вычислительной мощности среди pCPU, в зависимости от того, насколько загружен поток-близнец. Эта асимметрия ухудшает «справедливость распределения» (fairness). Например, один vCPU работает на частично загруженном ядре, а другой на полностью свободном. Если оба vCPU идентичны по требованиям к вычислительной мощности, то получается несправедливая ситуация, и от нее надо уходить.

    В связи с этой асимметрией планировщик рассчитывает потребление процессорной мощности в меньшем объеме для vCPU, расположенном на частично загруженном ядре. В случае если vCPU исполнялся на частично загруженном ядре на протяжении длительного времени, то планировщик может перенести данный vCPU на полностью свободное ядро с целью компенсации недополученной процессорной мощности. В противном случае данный vCPU может оказаться в ситуации постоянного отставания от других vCPU, работающих на полностью свободных ядрах. Компенсация выражается в том, что второй аппаратный поток ядра намеренно сохраняется незагруженным. В этом случае может быть неполной утилизация аппаратных потоков, однако общее снижение производительности достаточно незначительно, ввиду ограниченности потенциального прироста производительности из-за многопоточности.
    Внутреннее тестирование показывает, что последние поколения многопоточных процессоров демонстрируют больший прирост производительности и меньшее влияение загрузки потока-близнеца. Это наблюдение дает повод для более агрессивного использования частично загруженных ядер для балансировки нагрузки — полностью свободные ядра все еще предпочтительнее, но если нет полностью свободных, то частично загруженное ядро имеет больше шансов. Ранее частично загруженные ядро могло быть вовсе не выбранным для гарантии справедливого распределения процессорного времени. Эксперименты показывают, что агрессивное использование многопоточности улучшает утилизацию процессора и увеличивает производительность приложений без значительного влияния на справедливость распределения.
    Стоит заметить, что бухгалтерия планировщика слегка изменилась — загрузка процессора считается со скидкой, если поток-близнец загружен. Это приводит к ситуации, в которой общая загрузка системы считается меньше реальной. Например, возьмем ситуацию, в которой оба потока-близнеца постоянно загружены. В терминах утилизации процессора система полностью загружена, но в терминах бухгалтерии процесса время исполнения, которое будет списываться со счета исполняемых vCPU, меньше полной загрузки ввиду скидки. В esxtop для поддержки этого появился новый счетчик “PCPU Util” для отображения утилизации системы, а “PCPU Used” все еще показывает текущее время исполнения. Подробности — man esxtop.

    Extended Fairness Support

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

    Оригинал: «VMware® vSphere™: The CPU Scheduler in VMware ESX® 4.1»

    Антон Жбанков

    http://blog.vadmin.ru

Комментарии

  1. Добавь категорию «Новое», а то на первой странице не видно.

Опубликовать

Я не робот.