В третьей части мы посмотрим на то, как работает с оперативной памятью гипервизор, а также на техники, которые применяются для высвобождения памяти, когда её становится крайне мало.
Memory Sizing
Стоит внимательно подходить к вопросу выделения оперативной памяти виртуальной машине.
Рекомендуется выделять виртуальной машине достаточное количество оперативной памяти для работы системы и приложений и, одновременно, не стоит выделять значительно больше, чем требуется.
Нужно понимать, что чем больше памяти выделено машине – тем больше накладные расходы гипервиозра на обслуживание данной памяти (overhead). Даже если гипервизор сможет высвободить часть ресурсов из виртуальной машины, уменьшить оверхед уже не получится.
Memory Overcommit Techniques
ESXi использует 5 техник для оптимизации количества потребляемой ОЗУ, в случаях, если ее становится крайне мало.
Чем меньше свободной остается доступной памяти – тем более жесткие техники он начинает применять. Естественно, ни о какой высокой производительности тут не может идти и речи.
Page Sharing – в случае, если участки памяти двух виртуальных машин одинаковы, нет смысла держать два одинаковых участка и занимать двойное пространство ОЗУ, когда можно просто сослать обе машины на один участок памяти, а второй высвободить. До версии 6.0 Page Sharing работал между виртуальными машинами в рамках одного хоста, однако, с 6-й версии, по умолчанию данный метод применяется только внутри виртуальных машин в целях безопасности.
Ballooning – Модуль, который устанавливается в гостевую операционную систему вместе с пакетом VMware Tools, который может «подтолкнуть» гостевую ОС к высвобождению наименее важных страниц памяти.
Memory Compression – Тут все понятно из описания. Сжатие страниц памяти на хосте. Это, конечно, снижает скорость доступа к памяти, но все еще быстрее, чем использование swap файлов.
Swap to Host Cache – Включается своппинг на уровне хоста. Но в данном случае в кэш, если он, конечно, сконфигурирован. Swap to Host Cache позволяет выделить пространство на SSD, доступ к которому будет все еще быстрее, чем доступ к swap на обычном жестком диске.
Regular Host–Level Swapping – Когда нет свободной озу и заканчивается кэш, страницы памяти виртуальных машин начинают попадать в swap файл на хосте. Несложно догадаться, что это самая крайняя мера и до нее лучше не доводить. Доступ виртуальных машин к страницам памяти, располагаемым в swap файлах хоста будет очень медленным, по сравнению с доступом к страницам в оперативной памяти.
Несмотря на все вышеуказанные техники, которые позволяют выделить виртуальным машинам значительно большее количество ресурсов, чем есть на хосте, на котором они располагаются, до этого лучше не доводить.
Если имеется подозрение, что вышеуказанные техники начинают применяться к VM и это сказывается на ее производительности, следует проверить следующее:
- Проверить значения параметра Ballooning у виртуальной машины в меню Monitor – Performance – Advanced в разделе Memory. Нулевое значение данного параметра обычно говорит о том, что у хоста не наблюдается проблем с переподпиской (overcommitment) и ресурсов достаточно для облуживания виртуальной машины. Стоит помнить, что данный параметр имеется только у виртуальных машин с установленным Balloon Driver, который входит в пакет VMware Tools. Небольшое количество balloon memory не всегда говорит о наличии каких-либо проблем;
- Проверить раздел Utilization виртуальной машины. Отличные от нуля значения Swapped и Compressed могут говорить о нехватке памяти гипервизора. Обращение к данным участкам памяти будет замедленно, что скажется на производительности виртуальной машины;
- Стоит проверить активность использования файла подкачки в виртуальной машине. Это может говорить либо об активной процедуре балунинга, либо о недостаточном количестве памяти, выделенной виртуальной машине.
Memory Page Sharing
Как уже было сказано ранее, начиная с версии 6.0, Page sharing работает по умолчанию только в рамках виртуальной машины (intra-VM sharing). При необходимости, его можно включить между виртуальными машинами (inter-VM sharing), если у них выставлено одинаковое значение «salt».
В связи с большой распространенностью страниц памяти размером 2MB (large memory pages), которые не «шарятся», даже если параметр Page Sharing включен, использование дедупликации страниц будет иметь в большинстве случаев незначительный эффект.
В инсталляциях, где используется большое количество мелких страниц памяти (например, VDI, где используется больное количество однотипных машин), Page Sharing может оказаться полезным.
По умолчанию значение «salt» для виртуальной машины это ее uuid, который всегда уникален, что ограничивает Page Sharing рамками данной VM.
Для того, чтобы включить Page Sharing на всех виртуальных машинах хоста, необходимо выставить параметр Mem.ShareForceSalting в значение 0.
Либо, для включения Page Sharing между определенной группой виртуальных машин, можно использовать параметр sched.mem.pshare.salt в конфигурационном параметре VM.
Следует ознакомиться со статьями в базе знаний VMware (1 , 2 )
Memory Swapping Optimizations
Когда ESXi больше не может высвобождать память и оптимизировать ее использование в связи с высокой переподпиской, последней возможностью остается использование файлов подкачки на уровне хоста, что может сильно сказаться на производительности виртуальных машин.
Далее следуют рекомендации, как этого избежать, либо минимизировать негативный эффект:
- Не отключать Ballooning (не забывать устанавливать VMware Tools и следить за их работой в гостевой ОС), Page Sharing и Memory Compression;
- При включении виртуальной машины ESXi создает swap файл для данной VM, который равен размеру памяти машины за вычетом зарезервированной для нее ОЗУ. Следовательно, дисковых ресурсов на хранилище должно быть достаточно для размещения swap файлов машин;
- Если на хосте имеется SSD диск, не будет лишним задействовать его под кэш (Swatp to the Host Cache). Этот кэш доступен всем виртуальным машинам, располагаемым на хосте. Хороший вариант для SSD небольших размеров;
- Хорошим выбором будет размещение swap файлов виртуальных машин на самых скоростных доступных дисках. Лучший выбор – локальный для хоста SSD. Если объема SSD недостаточно для хранения swap файлов машин, лучше его задействовать под Host Cache;
- Если локальных SSD нет, следует размещать файлы на наиболее быстром доступном хранилище, подключенном, например, по Fibre Channel. К примеру, All-Flash массив;
- Независимо от типа используемого хранилища для лучшей производительности и избегания потенциальной ситуации, связанной с нехваткой доступного дискового пространства, не следует размещать файлы подкачки на thin-provisioned хранилище.
По умолчанию swap файл создается там же, где хранится vmx файл виртуальной машины, изменить данный параметр можно в Advanced секции настроек VM.
Уменьшить объем памяти, которая может оказаться в файле подкачки, либо вообще от него избавиться, можно, зарезервировав объем оперативной памяти для виртуальной машины.
Хорошая идея – зарезервировать для виртуальной машины тот объем памяти, с которым она регулярно работает.
В случае, если резерв выставлен во время работы виртуальной машины, эффект от резервирования появится не сразу и будет появляться постепенно. Для мгновенного эффекта стоит выключить и включить виртуальную машину (не перезагрузить из операционной системы, а именно выключить – включить).
Memory Overhead
Стоит понимать, что при использовании системы виртуализации, будут так же появляться и небольшие накладные расходы. Некоторое количество ОЗУ необходимо гипервизору и его службам, а часть ОЗУ для работы виртуальных машин. В целом дополнительно потребляемую память можно поделить на две категории:
- Как уже было сказано часть памяти используется непосредственно гипервизором и его службами (hostd, vpxa и т.п.). ESXi может использовать системный swap файл и уменьшить потребление ОЗУ до 1GB, в ситуациях когда памяти перестает хватать для работы виртуальных машин. Для использования данной возможности необходимо создать swap файл самостоятельно. esxcli sched swap system set -d true -n <datastore name>. Создается файл объемом 1GB на указанном хранилище;
- Дополнительная память используется для каждой запущенной виртуальной машины. Часть памяти резервируется для VMX процесса, часть для процесса VMM. Память резервируется также для виртуальных устройств (мышь, клавиатура, USB). Объем резервируемой оперативной памяти зависит от многих факторов, например, от количества vCPU, сконфигурированного объема памяти, 32-bit или 64-bit гостевая операционная система и т.п.
2MB Large Memory Pages
В дополнение к стандартным размерам страниц памяти в 4KB, ESXi так же может работать со страницами размером в 2MB (Large Pages).
ESXi назначает 2MB страницы гостевой ОС всегда, когда это возможно, даже если гостевая ОС их не запрашивает. Использование Large Pages снижает значения TLB miss, увеличивает производительность многих приложений, особенно, активно работающих с большими объемами памяти, так же уменьшаются служебные затраты ОЗУ на виртуальную машину.
ESXi не использует Page Sharing с большими страницами (скорее всего потому что найти пару двух одинаковых страниц достаточно тяжело). Однако, в случае нехватки оперативной памяти на хосте, большие страницы начинают дробиться на мелкие (4KB), задействуя при этом механизм Page Sharing.
На этом третья часть осмысления заканчивается. В следующей части рассмотрим советы, касающиеся работы с подсистемой хранения.
Все статьи по данному циклу:
Часть 1 – Hardware for Use with VMware vSphere;
Часть 2 – ESXi General Considerations и CPU;
Часть 3 – ESXi General Considerations и оперативная память;
Часть 4 – ESXi Storage Considerations;
Часть 5 – ESXi Networ Considerations;
Часть 6 – Guest Operating Systems.
