Насколько сильно я могу перегрузить физическую память моего хоста, назначив память моей гостевой машине?
Пример:
Физическая память хоста: 10 ГБ
Допустимо ли, например, назначить 2 ГБ виртуальной памяти 7 машинам, всего 14 ГБ? Насколько я могу перегрузить память, чтобы обеспечить правильную работу всплывающих окон и других методов освобождения памяти хоста?
Это в основном будет зависеть от виртуальных машин и их использования памяти. ESXi использует ряд методов, позволяющих чрезмерно использовать память для гостей:
Страницы памяти, которые некоторое время были неактивными, сжимаются, распаковываются и обслуживаются по запросу, вместо того, чтобы выгружаться на диск или раздуваться. Сжатие страниц имеет настраиваемый верхний предел, который по умолчанию составляет 10% от выделенной гостевой памяти, и вы можете приблизительно оценить снижение производительности на 6% при использовании кэша сжатия в реальных сценариях в соответствии с этот технический документ VMWare.
Страницы виртуальной памяти различных гостей, которые, как было установлено, несут идентичную информацию, ссылаются на одну и ту же страницу физической памяти. Это асинхронная операция, регулярно освобождающая повторяющиеся страницы памяти.
Драйвер уровня ядра в гостевой системе, поставляемой с инструментами VMWare, потребует память в невыгружаемом пуле памяти гостевой системы и пометит ее как «Свободную» для гипервизора. Таким образом, память фактически временно «украдена» у гостя, вызывая подкачку на уровне гостя, если гостю действительно нужна память.
Если все остальное не удается и требуется больше памяти, ESXi переставляет страницы гостевой памяти на диск. Расположение файла подкачки можно настроить и по умолчанию он помещается в тот же каталог, что и гостевые файлы конфигурации.
Я обнаружил, что для моих типичных нагрузок сжатие страниц и совместное использование страниц дает около 10% экономии памяти по сравнению с накладными расходами памяти, которые несет ESXi, без заметного снижения производительности. Воздушный шар всегда будет работать, если он настроен на (вы можете эффективно отключить его, зарезервировав весь объем памяти для гостя), но в основном это лишь незначительно лучше, чем замена (это то место, где ваши гости в противном случае динамически запрашивали бы большой объем памяти для кэширования, но если гости уже испытывают нехватку памяти, он не может творить чудеса и будет вызывать дисковый ввод-вывод из-за сбоя, как это произошло бы при подкачке на основе гипервизора).
Подводя итог: если бы вы могли настроить своих гостей с избыточной загрузкой всего около 10%, и они продолжали бы работать без подкачки в гостевой системе и сопутствующей деградации производительности, вы, вероятно, не возражали бы с вашей 40% -ой избыточностью. Если нет, то точно не станет.
Вывод страницы памяти esxtop (просто нажмите м после запуска esxtop из консоли SSH) будет информировать вас о статистике памяти в реальном времени более подробно, чем графики, которые вы получите с клиентом vSphere, поэтому, возможно, стоит посмотреть там:
1:54:52pm up 34 days 8:39, 214 worlds; MEM overcommit avg: 0.00, 0.00, 0.00
PMEM /MB: 32766 total: 1031 vmk, 29568 other, 2166 free
VMKMEM/MB: 32103 managed: 1926 minfree, 13525 rsvd, 18577 ursvd, high state
NUMA /MB: 8123 ( 767), 8157 ( 2425), 8157 ( 186), 7835 ( 128)
PSHARE/MB: 2162 shared, 139 common: 2023 saving
SWAP /MB: 0 curr, 0 rclmtgt: 0.00 r/s, 0.00 w/s
ZIP /MB: 17 zipped, 10 saved
MEMCTL/MB: 295 curr, 292 target, 14289 max