Случайно пару недель назад наткнулся на прошлогоднюю статью друга System32 про Прозрачный обмен страницами , что фактически побудило меня сорвать график подготовки к VCAP-DCA и углубиться в совершенно незнакомую мне технологию управления памятью в vSphere, а если быть точнее, в TPS. Коллега System32 очень толково изложил общие принципы работы с памятью и алгоритмом TPS, но при этом сделал несколько не совсем правильных выводов.
Еще больше меня спровоцировали вопросы в комментариях, на которые никто не ответил по поводу высоких значений SHRD памяти в esxtop, несмотря на то, что согласно той же статье, при использовании Large Pages технология TPS просто не будет работать.
В общем, между красивой теорией и практикой возникли серьезные противоречия.
После 4-5 дней копания на форумах Vmware, чтения Wiki, Западный блоггеры , что-то застряло у меня в голове и я наконец смог ответить на вопросы из комментариев.
Чтобы как-то систематизировать свои свежие знания, я решил написать на эту тему несколько статей в своем англоязычном блоге.
Я также рыскал на Хабре в поисках новых статей на эту тему, но к своему удивлению не нашел ничего нового с 2010 года.
Поэтому ради постоянно читаемого Хабра и возможности активно участвовать в комментариях решил перевести свою статья о Transparent Page Sharing и нюансах его использования на системах с процессорами семейства Nehalem/Opteron и с установленным ESX(i) 4.1. Я не хочу делать эту статью слишком длинной, поэтому настоятельно рекомендую вам (особенно если вы администратор vSphere) сначала прочитать статью, на которую я дал ссылку в самом начале.
Но все же повторюсь в некоторых мелких деталях.
Итак, для чего нужен ТПС? Ответ достаточно банален — экономить оперативную память, показывать виртуальным машинам больше памяти, чем доступно на самом хосте, а значит обеспечивать более высокий уровень консолидации.
Как он работает? Исторически сложилось так, что в системах x86 вся память разделена на блоки по 4 КБ, называемые страницами.
Когда у вас есть 20 виртуальных машин (ВМ) с одной и той же ОС, работающих на одном ESX-хосте, вы легко можете себе представить, что эти ВМ имеют довольно много одинаковых страниц памяти.
Для обнаружения идентичных страниц на хосте ESX процесс TPS запускается каждые 60 минут. Он сканирует абсолютно все страницы в памяти и вычисляет хеш каждой страницы.
Все хеши складываются в одну таблицу и проверяются ядром на совпадение.
Чтобы избежать проблемы, называемой хэш-столкновение При обнаружении идентичных хэшей ядро побитно проверяет соответствующие страницы.
И только убедившись в их 100% идентичности, ядро оставляет в памяти одну единственную копию страницы, и все запросы к удаленным страницам перенаправляются на эту самую первую копию.
Если какая-либо из ВМ решит изменить что-либо на этой странице, то ESX создаст еще одну копию исходной страницы и позволит ВМ, отправившей запрос на изменение, работать с ней.
Поэтому в терминологии Vmware этот тип страниц называется Copy-on-write (COW).
Процесс сканирования памяти на современных серверах с порой сотнями гигабайт оперативной памяти может занять довольно длительное время, поэтому не стоит ожидать немедленных результатов.
НУМА и ТПС НУМА — довольно интересная технология разделения доступа к памяти между процессорами.
К счастью для нас, последние версии ESX достаточно умны и знают, что для эффективности в системах NUMA TPS должен работать только внутри узла NUMA. В принципе, если настроить значение VMkernel.Boot.sharePerNode в ESX, можно заставить TPS сравнивать страницы внутри всей памяти, а не отдельные узлы NUMA. Понятно, что в этом случае можно добиться более высоких значений SHARED памяти, но нужно учитывать возможное серьёзное падение производительности.
Например, представьте, что ваш ESX-хост имеет 4 процессора Xeon 5560, то есть 4 узла NUMA и каждый из которых содержит идентичную копию страницы памяти.
Если TPS оставит одну копию в первом узле и удалит остальные 3, это означает, что каждый раз, когда какой-либо из ВМ, работающих на этих 3 узлах, потребуется требуемая страница памяти, 3 процессорам придется обращаться к ней не через локальную, а очень быструю память.
автобус, но сквозной и медленный.
Чем больше у вас таких страниц, тем меньше пропускной способности остается на общей шине, а значит, тем сильнее страдает производительность ваших виртуальных машин.
Ноль страниц Одной из замечательных новых функций, представленных в vSphere 4.0, было распознавание нулевых страниц.
В принципе, это обычная страница, которая от начала до конца заполнена нулями.
Каждый раз, когда виртуальная машина Windows включается, вся память обнуляется, это помогает ОС определить точный объем доступной ей памяти.
ESX может моментально обнаружить такие страницы в виртуальных машинах, и вместо бесполезного процесса выделения физической памяти под нулевые страницы с последующим их удалением во время работы TPS, ESX сразу перенаправляет все такие страницы на одну-единственную нулевую страницу.
Если вы запустите esxtop и проверите значения памяти для только что запущенной ВМ, то обнаружите, что значения ZERO и SHRD практически идентичны.
Однако здесь важно отметить, что ESX 4.0 (и более поздние версии) могут использовать эту новую замечательную функцию только на процессорах с технологиями EPT (Intel) или RVI (AMD).
На сайте Kingston есть пара отличных статей на эту тему ( Первая часть , часть вторая ).
Вкратце рассказывает и показывает, как на новых процессорах нулевые страницы распознаются без выделения им физической памяти, а на старых процессорах физическая память выделяется, и только когда TPS полностью отработает, начинается уменьшение используемой физической памяти.
Для обычных ферм vSphere это в принципе не критично, но для VDI-инфраструктур, где одновременно могут запускаться сотни виртуальных машин, это крайне полезно.
Пара особенностей TPS, работающих с нулевыми страницами.
1 .
В ОС Windows есть технология под названием «кэширование файловой системы» (прошу прощения, если в некоторых местах мой перевод названий и определений неточен).
Используя определение MS, мы можем сказать, что «Кэширование файловой системы — это область памяти, в которой хранится недавно использованная информация для быстрого доступа».
Этот кэш находится в адресном пространстве ядра, поэтому в 32-битных системах его размер ограничен 1 гигабайтом.
Однако на 64-битных системах его размер может достигать 1 терабайта ( доказательство ).
В принципе, технология очень полезна для производительности, но если у нас ситуация с виртуальными машинами и нулевыми большими страницами (2 мегабайта), то значение SHRD в esxtop будет стремиться к нулю.
На скриншоте выше показано значение esxtop сразу после запуска виртуальной машины Windows 2008 R2, но вот что esxtop показал через полчаса.
Хотя в Диспетчере задач этой виртуальной машины можно легко посмотреть, сколько у нас свободной (нулевой) памяти.
К сожалению, я так и не выяснил, почему все происходит именно так, но мне кажется, что кэширование файловой системы происходит не в виде непрерывной записи в память, а в различные ее области.
2 .
Страницы памяти в виртуальной машине сбрасываются только при ее включении.
При стандартной перезагрузке страницы не сбрасываются.
Большие страницы Размер больших страниц, используемых ядром в ESX, составляет 2 мегабайта.
Шансы на то, что в физической памяти найдутся две одинаковые большие страницы, практически равны нулю, поэтому ESX даже не пытается их сравнивать.
Когда вы используете новые процессоры с EPT/RVI, это означает, что хост будет агрессивно пытаться использовать большие страницы, когда это возможно.
Если вы посмотрите на значение SHRD у таких хостов, то будете неприятно удивлены его низким значением, но тем не менее это все равно значительная величина.
На моем производственном хосте при выделенных 70 ГБ около 4 ГБ были SHRD. Это, кстати, был один из самых интересных вопросов в комментариях к статье, с которого начался мой интерес к этой теме.
Сейчас я знаю, что это всего лишь ноль страниц, но тогда меня ужасно мучило незнание и догадки.
Это небольшое число изначально вызвало бурные дискуссии на форумах Vmware по той простой причине, что люди решили, что TPS вообще перестал работать на их хостах ESX 4.0. Vmware была вынуждена опубликовать разъяснение в этом случае.
Однако даже когда ваш хост активно использует большие страницы, TPS вообще не спит. Он также методично сканирует память на предмет идентичных страниц размером 4 КБ, которые он мог бы удалить, если бы захотел.
Как только он находит одинаковые страницы, он помещает туда закладку (подсказку).
Когда значение используемой памяти в ESX достигает 94%, ваш хост сразу разбивает большие страницы на мелкие и, не тратя время на сканирование (TPS уже настроил закладки), снова начинает удалять одинаковые страницы.
Если вы еще не дошли до этого, то в том же esxtop в поле COWH (Copy-on-writehints) можно посмотреть, сколько примерно можно сэкономить после разделения больших страниц на маленькие.
Опять же хотелось бы обратить ваше внимание на разницу в обработке больших страниц между старыми и новыми процессорами.
Сама Vmware включила поддержку больших страниц начиная с версии 3.5. Согласно документу « Производительность большой страницы » от Vmware, если ОС вашей виртуальной машины использует большие страницы, то хост ESX выделит большие страницы в физической памяти специально для этой ВМ.
Однако если та же виртуальная машина работает на хосте ESX с процессорами EPT/RVI, то независимо от поддержки больших страниц вашей ВМ, ESX будет использовать большие страницы в физической памяти, что, как известно из того же документа, приводит к серьезному увеличению производительности процессора.
Интересно, что на паре хостов со старыми процессорами и ESX 4.1, на которых на 90% установлена Windows 2008R2, я все еще вижу очень высокий SHRD, что говорит о том, что они, скорее всего, используют маленькие страницы.
К сожалению, я не нашел подробной документации о том, как работает поддержка больших страниц на старых процессорах: при каких условиях, на какой ОС и т.д. будут использоваться большие страницы.
Так что для меня это пока белое пятно.
В ближайшее время попробую запустить около 10 Windows 2008 R2 на хосте ESX 4.1 со старым процессором и проверить значения памяти.
Когда я только более-менее все это узнал, я был озадачен — что будет, если я вручную отключу поддержку больших страниц на своем хосте с процессором Nehalem? Сколько памяти я увижу сохраненным и насколько упадет производительность? «Ну зачем долго об этом думать — надо это сделать», — подумал я и отключил поддержку больших страниц на одном из наших производственных хостов.
Изначально на этом хосте было 70 ГБ выделенной памяти и 4 ГБ общей памяти (ну да, мы помним — это ноль страниц).
Средняя загрузка процессора никогда не поднималась выше 25%.
Через два часа после отключения больших страниц значение разделяемой памяти увеличилось до 32 ГБ, а загрузка процессора осталась на том же уровне.
С тех пор прошло уже 4 недели и мы еще не услышали ни одной жалобы на падение производительности.
И наконец мой вывод После того, как я поделился информацией с коллегами, они меня спросили: «Зачем вообще отключать поддержку больших страниц, если хостер и так их отключит при необходимостиЭ» И я сразу знал ответ — имея поддержку больших страниц, включенную по умолчанию, я не могу полностью увидеть, сколько памяти потенциально могу сэкономить с помощью TPS, не могу правильно спланировать дополнительное размещение ВМ на своих ESX-хостах, не могу Не могу прогнозировать уровень консолидации, вообще я немного слеп в плане управления ресурсами своей фермы vSphere. Однако гуру vSphere, например Дунканшппинг, уверял — «не волнуйтесь, TPS все равно сработает, когда нужно, и при этом вы получите отличный прирост производительности».
Еще через пару дней я нашел чудесный обсуждение между ним и другими авторитетами в мире виртуализации, что лишь подтвердило правильность моего решения отключить большие страницы.
Некоторые говорят, что вы можете использовать значение COWH для планирования использования своих ресурсов, но по каким-то причинам это значение не всегда соответствует действительности.
На этом снимке экрана показаны значения одного из моих серверов Windows 2003, который работал в течение 3 недель на хосте с отключенными большими страницами, и, как вы можете видеть, значения SHRD и COWH сильно различаются.
Неделю назад мы отключили большие страницы еще на 4 хостах, на другой ферме, и снова я не заметил никакого падения производительности.
Хотя, стоит отметить, что это все индивидуально, и при принятии такого решения вы должны учитывать специфику вашей фермы, ресурсов, виртуальных машин.
Если мне повезет и эта статья покажется интересной, то я буду рад перевести еще одну свою статью о разнице в управлении памятью между процессорами старого и нового поколения.
Теги: #Виртуализация #Прозрачный общий доступ к страницам #ESX ESXi vSphere Большие страницы
-
6 Обязательных Дистрибутивов Linux
19 Oct, 24 -
Jakarta Ee 8 Наконец-То Выпущена
19 Oct, 24 -
Простой Способ Справиться С Прокрастинацией
19 Oct, 24 -
Как Научиться Кататься На Моноколесе?
19 Oct, 24 -
Css Только Для Mozilla (Включая Firefox)
19 Oct, 24 -
Новый Проект - Linuxstart!
19 Oct, 24
