понедельник, 26 декабря 2011 г.

Trasparent Memory page Sharing + Large Pages + Address Space Layout Randomization

 

В 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% от максимума (гигабайт каждой), хотя активно используется лишь малая часть.

image

рис. 1-1.

 

Память не дедуплицируется вообще(!).

image

Рис. 1-2.

 

То же что и предыдущие данные, но обзорно. См. поле “Shared” в данных “Memory”.

image

Рис. 1-3.

 

Случай номер два

 

ВМ работают под нагрузкой. Все по умолчанию – большие страницы используются, ASLR включен.

 

Ситуация от предыдущей отличается только большей активно задействованной памятью. Обратите внимание – Windows 7 + Office 2010 потребляют порядка 400 МБ под нагрузкой от используемой мною утилиты, по крайней мере с настройками по умолчанию (правда, из доступной от нее документации нет ничего про какие-либо настройки уровня нагрузки).

image

Рис. 2-1.

 

Дедупликации по прежнему ноль.

image

Рис. 2-2.

 

image

Рис. 2-3.

 

На этом этапе теста я сообразил еще и в esxtop данные смотреть. Тут нас интересует строка c показателями PSHARE, shared, common, saving выше таблицы с данными по каждой ВМ. По идее, самый ценный показатель это saving – типа как раз “сколько TPS нам сэкономил”.

image

Рис. 2-4.

 

А вот это результаты работы VDI Sizing tools – эта утилита еще и графики по статистике рисует. К сожалению, на моем стенде данные не совсем мною поняты – многие графики, похоже, в районе нуля. И тяжело понять а синяя линия вот к чему именно относится?

У меня от бедности все ВМ лежат на одном диске, именно на одном физическом SATA диске – так что некоторые тормоза могут быть вызваны именно этим.

image

Рис. 2-5.

 

Случай номер три

 

ВМ без нагрузки. Выключены только большие страницы.

 

При сопоставимых значениях “активно используемой памяти” гипервизор тратит меньше “железной памяти” на каждого гостя.

image

Рис. 3-1.

 

Дедупликация заработала! График показан на этапе выхода на статичные показания.

image

Рис. 3-2.

 

На этих статичных показаниях дедуплицируется порядка 3 ГБ памяти этих 5 ВМ.

image

Рис. 3-3.

 

Нам экономят 2 ГБ из пяти, по данным esxtop.

image

Рис. 3-4.

 

Случай номер четыре

 

ВМ под нагрузкой. Большие страницы не используются.

 

Ситуация предсказуема – нагрузка есть, железной памяти выделяется не 100% от параметров ВМ.

image

Рис. 4-1.

 

Разделение памяти работает.

image

Рис. 4-2.

 

Порядка 2.5 ГБ разделяются.

image

Рис. 4-3.

 

Экономится чуть менее 2 ГБ.

image

Рис. 4-4.

 

Данные VDI Sizing tool. В первый раз какой-то один показатель достигал 30 секунд, потом опускался до 3. Сейчас он же, похоже, стабильно в районе 3 секунд. Остальное, как и было – в районе нуля.

Выводы – явным образом отключенные большие страницы тормозов не вызвали.

image

Рис. 4-5.

 

Случай номер пять

 

ВМ без нагрузки. Выключены и большие страницы, и ASLR.

Для выключения ASLR в реестре каждой ВМ был создан ключ DWORD со значением “0”, по адресу
\HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages

 

Хмм. Эффект похоже есть. Сравнивать следует с данными случая 3.

image

Рис. 5-1.

 

image

Рис. 5-2.

 

С включенным ASLR шарилось 2.95 ГБ. С выключенным – 3.76.

image

Рис. 5-3.

 

С ASLR esxtop показывал сохранение 2082 МБ.

image

Рис. 5-4.

 

Случай номер шесть

 

ВМ под нагрузкой, выключены и LP и ASLR

Сравнивать надо со случаем 4, когда ВМ под нагрузкой, но выключены только LP. Там ВМ занимали от 620 до 780 МБ.

image

Рис. 6-1.

 

Обратите внимание на пики переходного периода. Такой график может возникнуть вне зависимости от ASLR, это свойство TPS как такового. Я так предполагаю, что именно подобная нестабильность эффекта от TPS (обусловленная тем, что нагрузка на ВМ неравномерно меняется, а также тем что сами ВМ переезжают) и является причиной того, что VMware не рекомендует учитывать эффект от TPS в производственной среде. Впрочем, если состояние ВМ стабильно – то и эффект от TPS стабилен (см. все остальные графики #-2).

image

Рис. 6-2.

 

Расшаривается порядка 2.9 ГБ памяти. С ASLR – порядка 2.5.

image

Рис. 6-3.

 

Сэкономлено порядка 2.2 ГБ. С ASLR – порядка 1.8 ГБ.

image

Рис. 6-4.

 

Задержки одной из операций опять стали большие, для одной сессии. Непонятно, с чем это связано. Впрочем, учитывая что все остальное в районе нуля – похоже в моих масштабах от включения\выключения LP и ASLR не меняется ничего.

image

Рис. 6-5.

 

Случай номер семь

 

ВМ без нагрузки. ASLR выключен, большие страницы используются (т.е. настройки ESXi по умолчанию).

 

Экономия памяти по нулям.

image

Рис. 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 произвела хорошее впечатление – завелась сразу, это веский довод Улыбка

Однако немного непорадовала документация – я с первого раза понял что куда устанавливать, но дискомфорт во время разбирательства был.

13 комментариев:

  1. Интересно, не это ли причина, почему Win7 значительно хуже памятью делится, чем Win2008R2...

    P.S. большие страницы на хосте отключены, суперфетч на 7ках выключен.

    ОтветитьУдалить
  2. По чтениям материалов у меня сложилось впечатление, что ASLR для серверных Windows так же актуально.

    ОтветитьУдалить
  3. Добрый день!

    Михаил а какой командой вы в консоли просматриваете сколько удалось сэкономить RAM?

    Просто у меня в производственной среде (VDI) на одном сервере с 64Гб RAM ESXi (4.1) крутится 30 ВМ (Windows XP по 2Гб RAM) показывается Shared memory - 36 ГБ
    Вот мне интересно насколько это правда?

    ОтветитьУдалить
  4. Мдаа...
    Насколько этому можно верить?
    9:51:45am up 83 days 3:46, 417 worlds; MEM overcommit avg: 0.17, 0.17, 0.17
    PMEM /MB: 64509 total: 1446 vmk, 35158 other, 27904 free
    VMKMEM/MB: 63349 managed: 3800 minfree, 14467 rsvd, 48882 ursvd, high state
    PSHARE/MB: 39214 shared, 3864 common: 35350 saving
    SWAP /MB: 0 curr, 0 rclmtgt: 0.00 r/s, 0.00 w/s
    ZIP /MB: 0 zipped, 0 saved
    MEMCTL/MB: 0 curr, 0 target, 42588 max

    ОтветитьУдалить
  5. Если верить этому, то удалось сохранить 35Гб RAM

    ОтветитьУдалить
  6. Этому можно верить. Это можно даже повторить. Достаточно запустить гостя 2008R2 с выделенной ему памятью гиг в 60, и увидим даже больше. 0,6ГБ будет занято сразу после старта, всё остальное попадет в saving. Лично я видел на 16ГБ хосте, 12ГБ saving при 24 выделенного гостям, когда "шаблоны" были загружены ради установки обновлений.

    ОтветитьУдалить
  7. типа "это слишком хорошо чтобы быть правдой" ? :-)

    а сколько на этом сервере "сконфигуренной" памяти для всех ВМ?

    ОтветитьУдалить
  8. Михаил, это ко мне вопрос был? Если да, то ответ смысла не имеет. Мне оно для тестов надо. Все гости одновременно не запускаются никогда.

    Кстати, нашел в истории и "скрин" с того случая (кажется, это еще ESXi4 был):
    PMEM /MB: 16328 total: 948 vmk, 12056 other, 3323 free
    VMKMEM/MB: 16249 managed: 652 minfree, 3262 rsvd, 12986 ursvd, high state
    PSHARE/MB: 14047 shared, 1536 common: 12511 saving
    SWAP /MB: 203 curr, 44 rclmtgt: 0.00 r/s, 0.00 w/s
    ZIP /MB: 235 zipped, 152 saved
    MEMCTL/MB: 103 curr, 103 target, 15862 max

    Жалко тут granted нет, но насколько я помню, около 24ГБ на графике было в тот момент. Зато и своп и пожатое видно. Сразу скажу, своп и пожатое образовалось до конкретно этого эксперимента. Как можно видеть, 3,3 ГБ прямо сейчас еще и свободно.

    Так что, если выключение ASLR поможет еще спасти памяти, это вообще из разряда "очевидное-невероятное" будет.

    PS Михаил, Вы бы разрешили теги < code > и/или < pre > для комментариев...

    ОтветитьУдалить
  9. Ну как то так:

    http://saveimg.ru/pictures/27-12-11/c58028bc2b4ff65a539e81e79221b319.jpg

    ОтветитьУдалить
  10. ну вот получается что всего памяти 64 ГБ, настроено ВМ на примерно 68, а реально потрачено (consumed) ~42 ГБ.

    ОтветитьУдалить
  11. И как тогда относиться к этому:
    8:55:49am up 84 days 2:50, 415 worlds; MEM overcommit avg: 0.20, 0.20, 0.20
    PMEM /MB: 64509 total: 1448 vmk, 40335 other, 22724 free
    VMKMEM/MB: 63349 managed: 3800 minfree, 15052 rsvd, 48296 ursvd, high state
    PSHARE/MB: 36079 shared, 3774 common: 32305 saving
    SWAP /MB: 0 curr, 0 rclmtgt: 0.00 r/s, 0.00 w/s
    ZIP /MB: 0 zipped, 0 saved
    MEMCTL/MB: 0 curr, 0 target, 43919 max

    Вроде бы сохранено 32Гб RAM, при потраченной 42Гб.

    ОтветитьУдалить
  12. ну как относится - это значит что без TPS вам бы потребовалось на 32 ГБ памяти больше для работы сейчас запущенных ВМ.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.