В rss ридере проскочил пост на тему что некая фича ASLR (Address Space Layout Randomization), реализованная, в частности, для Windows начиная с Vista, может влиять на эффективность дедупликации памяти, TPS. В конце поста я приведу ссылки и выжимки.
Мне стало интересно – ранее в таком контексте мне приходилось читать упоминания только про большие страницы, Large pages.
И я попробовал собрать свой собственный тестовый стенд.
Итак –
ESXi пятой версии, 16 ГБ ОЗУ.
Пять ВМ с Windows 7 (развернуты из одного шаблона). Внутри MS Office 2010. У каждой ВМ гигабайт памяти.
Эти ВМ запускаются, и я снимаю данные с показателя shared, отображающего эффективность TPS.
Притом, меня интересует сценарий простаивающих ВМ и ВМ под нагрузкой, и в случае разных комбинаций настроек.
Для создания нагрузки на эти ВМ я воспользовался утилитой VDI Sizing tool, которая довольно легко обеспечила имитацию офисной нагрузки для этих ВМ – в запущенных ею RDP-сессиях на мои Win7 запускались Word, Excel, Outlook, в них печатался текст, вставлялись картинки и т.д. и т.п. Выбор именно этой утилиты был обусловлен тем, что мне давно было интересно попробовать ее в деле.
К сожалению, в списке поддерживаемых для тестирования были заявлены только серверные Windows, а я использовал Windows 7. Но я заметил только две проблемы – Outlook 2010 требовал нажатия на ОК с вопросом об имени какого-то файла. Вторая проблема – данные со статистикой про латенси разных операций оказались непонятными – выделялись только графики пары-тройки показателей. Остальное то ли совпадало, то ли было в районе нуля, то ли что. Может у меня просто мало ВМ в тесте участвовало.
Данный стенд вряд ли потянет на супер-отличный-стенд-к-организации-которого-не-придраться, но и пофиг, правда? Зато я его сделал, и для понимания “на пальцах” он сойдет. Однако!!! Далеко идущие выводы из результатов стоит делать с осторожностью.
Случай номер один
ВМ без нагрузки. Все по умолчанию – большие страницы используются, ASLR включен.
Получившаяся ситуация:
С учетом избытка памяти на хосте (5 ВМ по гигабайту, на сервере всего 16), гипервизор выдал каждой ВМ по 100% от максимума (гигабайт каждой), хотя активно используется лишь малая часть.
рис. 1-1.
Память не дедуплицируется вообще(!).
Рис. 1-2.
То же что и предыдущие данные, но обзорно. См. поле “Shared” в данных “Memory”.
Рис. 1-3.
Случай номер два
ВМ работают под нагрузкой. Все по умолчанию – большие страницы используются, ASLR включен.
Ситуация от предыдущей отличается только большей активно задействованной памятью. Обратите внимание – Windows 7 + Office 2010 потребляют порядка 400 МБ под нагрузкой от используемой мною утилиты, по крайней мере с настройками по умолчанию (правда, из доступной от нее документации нет ничего про какие-либо настройки уровня нагрузки).
Рис. 2-1.
Дедупликации по прежнему ноль.
Рис. 2-2.
Рис. 2-3.
На этом этапе теста я сообразил еще и в esxtop данные смотреть. Тут нас интересует строка c показателями PSHARE, shared, common, saving выше таблицы с данными по каждой ВМ. По идее, самый ценный показатель это saving – типа как раз “сколько TPS нам сэкономил”.
Рис. 2-4.
А вот это результаты работы VDI Sizing tools – эта утилита еще и графики по статистике рисует. К сожалению, на моем стенде данные не совсем мною поняты – многие графики, похоже, в районе нуля. И тяжело понять а синяя линия вот к чему именно относится?
У меня от бедности все ВМ лежат на одном диске, именно на одном физическом SATA диске – так что некоторые тормоза могут быть вызваны именно этим.
Рис. 2-5.
Случай номер три
ВМ без нагрузки. Выключены только большие страницы.
При сопоставимых значениях “активно используемой памяти” гипервизор тратит меньше “железной памяти” на каждого гостя.
Рис. 3-1.
Дедупликация заработала! График показан на этапе выхода на статичные показания.
Рис. 3-2.
На этих статичных показаниях дедуплицируется порядка 3 ГБ памяти этих 5 ВМ.
Рис. 3-3.
Нам экономят 2 ГБ из пяти, по данным esxtop.
Рис. 3-4.
Случай номер четыре
ВМ под нагрузкой. Большие страницы не используются.
Ситуация предсказуема – нагрузка есть, железной памяти выделяется не 100% от параметров ВМ.
Рис. 4-1.
Разделение памяти работает.
Рис. 4-2.
Порядка 2.5 ГБ разделяются.
Рис. 4-3.
Экономится чуть менее 2 ГБ.
Рис. 4-4.
Данные VDI Sizing tool. В первый раз какой-то один показатель достигал 30 секунд, потом опускался до 3. Сейчас он же, похоже, стабильно в районе 3 секунд. Остальное, как и было – в районе нуля.
Выводы – явным образом отключенные большие страницы тормозов не вызвали.
Рис. 4-5.
Случай номер пять
ВМ без нагрузки. Выключены и большие страницы, и ASLR.
Для выключения ASLR в реестре каждой ВМ был создан ключ DWORD со значением “0”, по адресу
\HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages
Хмм. Эффект похоже есть. Сравнивать следует с данными случая 3.
Рис. 5-1.
Рис. 5-2.
С включенным ASLR шарилось 2.95 ГБ. С выключенным – 3.76.
Рис. 5-3.
С ASLR esxtop показывал сохранение 2082 МБ.
Рис. 5-4.
Случай номер шесть
ВМ под нагрузкой, выключены и LP и ASLR
Сравнивать надо со случаем 4, когда ВМ под нагрузкой, но выключены только LP. Там ВМ занимали от 620 до 780 МБ.
Рис. 6-1.
Обратите внимание на пики переходного периода. Такой график может возникнуть вне зависимости от ASLR, это свойство TPS как такового. Я так предполагаю, что именно подобная нестабильность эффекта от TPS (обусловленная тем, что нагрузка на ВМ неравномерно меняется, а также тем что сами ВМ переезжают) и является причиной того, что VMware не рекомендует учитывать эффект от TPS в производственной среде. Впрочем, если состояние ВМ стабильно – то и эффект от TPS стабилен (см. все остальные графики #-2).
Рис. 6-2.
Расшаривается порядка 2.9 ГБ памяти. С ASLR – порядка 2.5.
Рис. 6-3.
Сэкономлено порядка 2.2 ГБ. С ASLR – порядка 1.8 ГБ.
Рис. 6-4.
Задержки одной из операций опять стали большие, для одной сессии. Непонятно, с чем это связано. Впрочем, учитывая что все остальное в районе нуля – похоже в моих масштабах от включения\выключения LP и ASLR не меняется ничего.
Рис. 6-5.
Случай номер семь
ВМ без нагрузки. ASLR выключен, большие страницы используются (т.е. настройки ESXi по умолчанию).
Экономия памяти по нулям.
Рис. 7-2.
Таким образом, в моем исследовании получается, что для TPS первично отключение больших страниц. Отключение ASLR способно дополнительно улучшить эффект от TPS. При больших страницах эффект от TPS никакой, вне зависимости от ASLR.
Материалы
Исходный пост, привлекший мое внимание – Windows 7 Transparent Page Sharing and the ASLR story…
Там приводится краткое описание что такое Address Space Layout Randomization (ASLR) – это фича повышения безопасности. Типа какие-то адреса страниц памяти случайно меняются.
Отключение этой фичи однозначно не рекомендуется Microsoft – из общих соображений безопасности.
По вышеприведенной ссылке, тем не менее, попробовали отключить и провести тест TPS (мои стенд довольно похож, но здесь развертывалось 52 и больше ВМ с гигабайтом памяти каждая, на сервере с 48 ГБ ОЗУ).
По их данным, отключение ASLR давало порядка 30% повышения эффективности дедупликации памяти. Однако, большие страницы они, похоже, не отключали. У меня работа с большими страницами давала нулевой эффект дедупликации. Возможно дело в том, что они разворачивали ВМ на больше памяти чем есть на сервере – в таком случае ESXi автоматически отключает Large Pages, дедупликация начинает работать и отключенный ASLR повышает ее эффект.
Уже запустил у себя пул View для воспроизведения такой же ситуации – но уже хочется спать, напишу отдельным постом.
Доптвики для оптимизации TPS - Increase VDI consolidation ratio with TPS tuning on ESX.
Про отключение больших страниц от тех же авторов - TPS, Large Memory Pages and your VDI environment.
Про большие страницы у меня – TPS vs. Large Pages in real life.
Плохо ли отключение больших страниц – непонятно. Насколько я смог понять – в теории эффект есть, но на практике о пойманном эффекте “я отключил большие страницы и все стало плохо” не встретился.
Вот тут еще можно глянуть – boot storm. TPS vs. hardware MMU.
VDI Sizing tools произвела хорошее впечатление – завелась сразу, это веский довод 
Однако немного непорадовала документация – я с первого раза понял что куда устанавливать, но дискомфорт во время разбирательства был.
Сообщения
