Как вы, должно быть, знаете, у ESX(i) есть несколько технологий для повышения эффктивности использования памяти. (если кто не до конца в теме см. тут - Memory management).
Одна из технологий - Transparent memory page sharing, дедупликация оперативной памяти.
Гипервизор подсчитывает контрольную сумму страниц памяти виртуальных машин, находит одинаковые - и одинаковые страницы разных виртуалок в реальной оперативной памяти адресует в единственную копию.
По умолчанию, сканирование происходит раз в час, что должно быть достаточно хорошо для большей части случаев.
Однако вот тут - Increase VDI consolidation ratio with TPS tuning on ESX - описывается мнение что для VDI имеет смысл уменьшить частоту сканирования (с 60 до 10 минут). И довольно внушающая аргументация - часто много виртуальных рабочих станций одновременно включается, примерно в одно время на них начинают и заканчивают работать пользователи, часто в одно время случаются пики из за старта антивирусов и другого ПО. Если сканирование памяти будет быстрее отлавливать эти массовые изменения - экономия будет более эффективной.
Это первая часть поста.
Однако, есть нюанс касательно page sharing в целом, актуальный и для VDI при использовании Windows 7 - Large Pages.
Современные серверы позволяют операционным системам использовать большие страницы памяти (Large Pages). Операционные системы могу адресовать память страницами по два мегабайта, а не по четыре килобайта.
Это значительно сокращает размер таблицы адресов страниц, ускоряя работу с памятью когда этой памяти много. Обычно говорят о 10-20% повышении эффективности (см. Large Page Performance.)
Интересно, что сам ESX(i) вроде как поддерживает работу с большими страницами, и старается их использовать для памяти даже тех гостей, что сами по себе их использовать не обучены. (в том смысле что cам ESX(i) использует большие страницы для той памяти, что он выделил этому гостю, а сам гость работает по старинке "внутри" выделенного куска памяти). Правда, непонятно как это влияет на эффективность TPS.
Однако при использовании Large Pages эффективность дедупликации начинает уменьшаться, и очень значительно - найти абсолютно идентичные 2 мегабайта намного сложнее, чем идентичные 4 килобайта (см. немного подробнее на русском тут - Продолжаем говорить о памяти – Page Sharing).
Интересно, что при недостатке свободной ОЗУ на сервере ESX(i) начинает сам разбивать большие страницы на маленькие 4хкилобайтные, для возвращения эффективности Page Sharing.
(см. Transparent Page Sharing is not utilized under normal workloads on Nehalem based Xeon 5500 series CPUs.)
Известная мне теория гласит, что:
1) При использовании серверов на последней платформе (Nehalem у Intel и не знаю как называется у AMD), которые обладают поддержкой EPT\RVI
и при запуске современных ОС, умеющих работать с большими страницами
эти большие страницы используются, что приводит к околонулевой эффективности Page Sharing (исключая пустые страницы памяти, если они есть).
2) Можно отключить использование Large Pages.
Можно отключить использование LP для всех ВМ хоста, при помощи настройки
Mem.AllocGuestLargePage to 0
Можно отключить использование LP для отдельной ВМ правкой ее конфига:
monitor_control.disable_mmu_largepages = TRUE
В этом случае есть немалая вероятность что сервер начнет показывать, что свободной памяти стало больше - за счет дедупликации. Но может снизиться производительность. Однако, снижение производительности вероятно для ВМ с большим объемом ОЗУ (от 4 ГБ? от 8 ГБ?), и менее вероятно для ВМ с меньшими объемами.
Коллеги, если в теории я нигде не ошибся, остается тестировать ;-)
Одна из технологий - Transparent memory page sharing, дедупликация оперативной памяти.
Гипервизор подсчитывает контрольную сумму страниц памяти виртуальных машин, находит одинаковые - и одинаковые страницы разных виртуалок в реальной оперативной памяти адресует в единственную копию.
По умолчанию, сканирование происходит раз в час, что должно быть достаточно хорошо для большей части случаев.
Однако вот тут - Increase VDI consolidation ratio with TPS tuning on ESX - описывается мнение что для VDI имеет смысл уменьшить частоту сканирования (с 60 до 10 минут). И довольно внушающая аргументация - часто много виртуальных рабочих станций одновременно включается, примерно в одно время на них начинают и заканчивают работать пользователи, часто в одно время случаются пики из за старта антивирусов и другого ПО. Если сканирование памяти будет быстрее отлавливать эти массовые изменения - экономия будет более эффективной.
Это первая часть поста.
Однако, есть нюанс касательно page sharing в целом, актуальный и для VDI при использовании Windows 7 - Large Pages.
Современные серверы позволяют операционным системам использовать большие страницы памяти (Large Pages). Операционные системы могу адресовать память страницами по два мегабайта, а не по четыре килобайта.
Это значительно сокращает размер таблицы адресов страниц, ускоряя работу с памятью когда этой памяти много. Обычно говорят о 10-20% повышении эффективности (см. Large Page Performance.)
Интересно, что сам ESX(i) вроде как поддерживает работу с большими страницами, и старается их использовать для памяти даже тех гостей, что сами по себе их использовать не обучены. (в том смысле что cам ESX(i) использует большие страницы для той памяти, что он выделил этому гостю, а сам гость работает по старинке "внутри" выделенного куска памяти). Правда, непонятно как это влияет на эффективность TPS.
Однако при использовании Large Pages эффективность дедупликации начинает уменьшаться, и очень значительно - найти абсолютно идентичные 2 мегабайта намного сложнее, чем идентичные 4 килобайта (см. немного подробнее на русском тут - Продолжаем говорить о памяти – Page Sharing).
Интересно, что при недостатке свободной ОЗУ на сервере ESX(i) начинает сам разбивать большие страницы на маленькие 4хкилобайтные, для возвращения эффективности Page Sharing.
(см. Transparent Page Sharing is not utilized under normal workloads on Nehalem based Xeon 5500 series CPUs.)
Известная мне теория гласит, что:
1) При использовании серверов на последней платформе (Nehalem у Intel и не знаю как называется у AMD), которые обладают поддержкой EPT\RVI
и при запуске современных ОС, умеющих работать с большими страницами
эти большие страницы используются, что приводит к околонулевой эффективности Page Sharing (исключая пустые страницы памяти, если они есть).
2) Можно отключить использование Large Pages.
Можно отключить использование LP для всех ВМ хоста, при помощи настройки
Mem.AllocGuestLargePage to 0
Можно отключить использование LP для отдельной ВМ правкой ее конфига:
monitor_control.disable_mmu_largepages = TRUE
В этом случае есть немалая вероятность что сервер начнет показывать, что свободной памяти стало больше - за счет дедупликации. Но может снизиться производительность. Однако, снижение производительности вероятно для ВМ с большим объемом ОЗУ (от 4 ГБ? от 8 ГБ?), и менее вероятно для ВМ с меньшими объемами.
Коллеги, если в теории я нигде не ошибся, остается тестировать ;-)
Миш,
ОтветитьУдалитьа ты не натыкался нигде на упоминание, что отключение LP для конкретных ВМ не работает?
Или как посмотреть размер страниц?
Суть вопроса, LP отключил для десятка win7, а shared 0.
Не, ничего такого не встречал :-(
ОтветитьУдалитьПри отключении рестарт хоста нужен?
ОтветитьУдалитьПрошу прощения,
ОтветитьУдалитьПри отключении LP рестарт хоста нужен?
теория гласит что достаточно ребутнуть ВМ, или мигрировать их на другой хост затем обратно на этот.
ОтветитьУдалитьЯ LP на самом хосте для всех ВМ отключал
ОтветитьУдалитья о том же.
ОтветитьУдалитьsorry Все понял )
ОтветитьУдалить