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"
четверг, 29 декабря 2011 г.
Подписаться на:
Комментарии к сообщению (Atom)
Сообщения
Добрый день, Антон
ОтветитьУдалитьВы пишите:
Однако, в силу стоимости самой миграции, происходит это не так часто, обычно раз в несколько секунда, чтобы снизить негативное влияние на общую производительности.
В документации написано так:
Although there is a cost incurred from this type of migration, it happens infrequently enough, typically at a few seconds, so that the performance impact is minimized.
Как мне кажется, то что написано у Вас и то, что в документации - это не одно и тоже.
---
Deshifrator
И как же, по-Вашему будет правильно перевести данную фразу?
ОтветитьУдалитьВаша основная мысль в том, что миграции происходят раз в несколько секунд.Что, как мне кажется, очень часто. А в документации говорится (IMHO), что подобные миграции случаются достаточно редко и всего-навсего на несколько секунд, что особо не влияет на производительность.
ОтветитьУдалить---
Deshifrator
Поддерживаю, дешифратора.
ОтветитьУдалитьЕсли приведенная цитата правильная, то миграции это плохо, но нестращно, потому как происходят редко и процесс миграции занимает несколько секунд.
Коллеги, по смыслу не подходит.
ОтветитьУдалитьРассматриваемая миграция - не vMotion, который несколько секунд занимает, а всего лишь переключение исполнения vCPU на другой pCPU. Почему есть смысл раз В несколько секунд, а не НА несколько секунд. Раз в несколько секунд уже автоматически говорит о том, что миграции могут быть на несколько секунд, а могут быть и на более длительное время. Плюс подразумевается однократные затраты на миграцию - прогрев кэша и так далее. На несколько секунд удваивает затраты, ведь надо еще мигрировать назад.
К сожалению, у Вас нигде не упомянуто про то, сколько все-таки длится миграция внутри LLC и между, и сколько нужно времени для разогрева кэша. Поэтому, в моём понимании, миграция раз в несколько секунд - это очень часто с учетом разогрева кэша. А разогрев кэша, как вы писали в предыдущей статье, очень сильно влияет на реальную стоимость миграции.
ОтветитьУдалитьВозвращаясь к вопросу, как бы я перевел:
To extend fairness support, the long-term fairness migration might happen to fairly allocate on-chip cache or memory bandwidth.
Although CPU resources are fairly allocated, there still can be migrations to improve fair allocation of on-chip cache or memory
bandwidth. Although there is a cost incurred from this type of migration, it happens infrequently enough, typically at a few seconds,
so that the performance impact is minimized.
Для улучшения справедливого распределения ресурсов, могут случаться долгосрочные миграции с целью обеспечения на кристалле достаточного количества кэша и пропускной способности к памяти. Несмотря на затраты, понесенные от этого вида миграции, это случается достаточно редко и, как правило, на несколько секунд, что не оказывает существенного влияния на производительность.
P.S. Одно из трех предложений я не стал переводить, так как оно не несет в себе ничего нового.
---
Deshifrator