Guest mem vmware что это

Обновлено: 05.07.2024

If you're looking at the VM tab, there are 3 columns that you may be seeing:

The metrics here is showing you how much of a particular VM is consuming from the ESX(i) host that it's being hosted on. Yes, you're correct that active memory is generally lower but it does not always have to be. This is just a metric to show you how much of that memory is actually being actively used from the overall allocated memory.

For example I have a 2vCPU x 2GB vMEM

Consumed cpu is 359 Mhz from the host

Consumed mem is 1.67GB from the host (this is what the host has allocated to the VM)

Active guest mem 204 MB (the current amount of active guest memory in the OS)

When you asked earlier what is "Consumed memory", I thought you were referring to the ESX(i) host metrics. The values you're looking at here, refers to a VM and per the reference doc:

"Consumed Memory" for a VM is:

Virtual machine: Amount of guest physical memory consumed by the virtual machine for guest memory. Consumed memory does not include overhead memory. It includes shared memory and memory that might be reserved, but not actually used. Use this metric for charge-back purposes.

Hopefully this makes more sense.

VMware vExpert 2009

VMware ESX/ESXi scripts and resources at:

If you find this information useful, please award points for "correct" or "helpful".

skayser

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

William already pointed out the definitions of active vs. host memory. Let me add another 2c: what tends to confuse people is a rather high consumed host memory versus a low active guest memory . usually followed by the question on how exactly active guest memory is calculated. Understanding Memory Resource Management in VMware® ESX™ Server includes some background for both.

1) Why is consumed host memory usage higher than active guest memory? (p.5)

"The hypervisor knows when to allocate host physical memory for a virtual machine because the first memory access from the virtual machine to a host physical memory will cause a page fault that can be easily captured by the hypervisor. However, it is difficult for the hypervisor to know when to free host physical memory upon virtual machine memory deallocation because the guest operating system free list is generally not publicly accessible. Hence, the hypervisor cannot easily find out the location of the free list and monitor its changes."

So the host allocates memory pages upon their first request from the guest (that's why consumed is less than the configured maximum), but doesn't deallocate them once they are freed in the guest OS (because the host simply doesn't see those guest deallocations). If the guest OS re-uses such previously allocated pages, the host won't allocate more host memory. If the guest OS however allocates different pages, the host will also allocate more memory (up to the point where all configured memory pages for the specific guest have been allocated).

2) How is active guest memory calculated? (p.12)

"At the beginning of each sampling period, the hypervisor intentionally invalidates several randomly selected guest physical pages and starts to monitor the guest accesses to them. At the end of the sampling period, the fraction of actively used memory can be estimated as the fraction of the invalidated pages that are re-accessed by the guest during the epoch".

In other words, the active guest memory is calculated from outside the guest by an approximation on the hypervisor level.

Немного теории

Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, ESXi начинает применять техники оптимизации потребления оперативной памяти (memory reclamation techniques). В противном случае операционные системы ВМ падали бы с ошибками доступа к ОЗУ.

Какие техники применять ESXi решает в зависимости от загруженности оперативной памяти:

Состояние памяти	Граница	Действия
High	400% от minFree	После достижения верхней границы, большие страницы памяти разбиваются на маленькие (TPS работает в стандартном режиме).
Clear	100% от minFree	Большие страницы памяти разбиваются на маленькие, TPS работает принудительно.
Soft	64% от minFree	TPS + Balloon
Hard	32% от minFree	TPS + Compress + Swap
Low	16% от minFree	Compress + Swap + Block

minFree — это оперативная память, необходимая для работы гипервизора.

До ESXi 4.1 включительно minFree по умолчанию было фиксированным — 6% от объема оперативной памяти сервера (процент можно было поменять через опцию Mem.MinFreePct на ESXi). В более поздних версиях из-за роста объемов памяти на серверах minFree стало рассчитываться исходя из объема памяти хоста, а не как фиксированное процентное значение.

Значение minFree (по умолчанию) считается следующим образом:

Процент памяти, резервируемый для minFree	Диапазон памяти
6%	0-4 Гбайт
4%	4-12 Гбайт
2%	12-28 Гбайт
1%	Оставшаяся память

Например, для сервера со 128 Гбайт RAM значение MinFree будет таким:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Мбайт = 1,88 Гбайт
Фактическое значение может отличаться на пару сотен МБайт, это зависит от сервера и оперативной памяти.

Процент памяти, резервируемый для minFree	Диапазон памяти	Значение для 128 Гбайт
6%	0-4 Гбайт	245,76 Мбайт
4%	4-12 Гбайт	327,68 Мбайт
2%	12-28 Гбайт	327,68 Мбайт
1%	Оставшаяся память (100 Гбайт)	1024 Мбайт

Обычно для продуктивных стендов нормальным можно считать только состояние High. Для стендов для тестирования и разработки приемлемыми могут быть состояния Clear/Soft. Если оперативной памяти на хосте осталось менее 64% MinFree, то у ВМ, работающих на нем, точно наблюдаются проблемы с производительностью.

В каждом состоянии применяются определенные memory reclamation techniques начиная с TPS, практически не влияющего на производительность ВМ, заканчивая Swapping’ом. Расскажу про них подробнее.

Transparent Page Sharing (TPS). TPS — это, грубо говоря, дедупликация страниц оперативной памяти виртуальных машин на сервере.

ESXi ищет одинаковые страницы оперативной памяти виртуальных машин, считая и сравнивая hash-сумму страниц, и удаляет дубликаты страниц, заменяя их ссылками на одну и ту же страницу в физической памяти сервера. В результате потребление физической памяти снижается и можно добиться некоторой переподписки по памяти практически без снижения производительности.

Источник

По умолчанию ESXi выделяет память большим страницам. Разбивание больших страниц на маленькие начинается при достижении порога состояния High и происходит принудительно, когда достигается состояние Clear (см. таблицу состояний гипервизора).

Если же вы хотите, чтобы TPS начинал работу, не дожидаясь заполнения оперативной памяти хоста, в Advanced Options ESXi нужно установить значение “Mem.AllocGuestLargePage” в 0 (по умолчанию 1). Тогда выделение больших страниц памяти для виртуальных машин будет отключено.

С декабря 2014 во всех релизах ESXi TPS между ВМ по умолчанию отключен, так как была найдена уязвимость, теоретически позволяющая получить из одной ВМ доступ к оперативной памяти другой ВМ. Подробности тут. Информация про практическую реализацию эксплуатации уязвимости TPS мне не встречалось.

Политика TPS контролируется через advanced option “Mem.ShareForceSalting” на ESXi:
0 — Inter-VM TPS. TPS работает для страниц разных ВМ;
1 – TPS для ВМ с одинаковым значением “sched.mem.pshare.salt” в VMX;
2 (по умолчанию) – Intra-VM TPS. TPS работает для страниц внутри ВМ.

Однозначно имеет смысл выключать большие страницы и включать Inter-VM TPS на тестовых стендах. Также это можно использовать для стендов с большим количеством однотипных ВМ. Например, на стендах с VDI экономия физической памяти может достигать десятков процентов.

Memory Ballooning. Ballooning уже не такая безобидная и прозрачная для операционной системы ВМ техника, как TPS. Но при грамотном применении с Ballooning’ом можно жить и даже работать.

Вместе с Vmware Tools на ВМ устанавливается специальный драйвер, называемый Balloon Driver (он же vmmemctl). Когда гипервизору начинает не хватать физической памяти и он переходит в состояние Soft, ESXi просит ВМ вернуть неиспользуемую оперативную память через этот Balloon Driver. Драйвер в свою очередь работает на уровне операционной системы и запрашивает свободную память у нее. Гипервизор видит, какие страницы физической памяти занял Balloon Driver, забирает память у виртуальной машины и возвращает хосту. Проблем с работой ОС не возникает, так как на уровне ОС память занята Balloon Driver’ом. По умолчанию Balloon Driver может забрать до 65% памяти ВМ.

Если на ВМ не установлены VMware Tools или отключен Ballooning (не рекомендую, но есть KB:), гипервизор сразу переходит к более жестким техникам отъема памяти. Вывод: следите, чтобы VMware Tools на ВМ были.

Работу Balloon Driver’а можно проверить из ОС через VMware Tools.

Memory Compression. Данная техника применяется, когда ESXi доходит до состояния Hard. Как следует из названия, ESXi пытается сжать 4 Кбайт страницы оперативной памяти до 2 Кбайт и таким образом освободить немного места в физической памяти сервера. Данная техника значительно увеличивает время доступа к содержимому страниц оперативной памяти ВМ, так как страницу надо предварительно разжать. Иногда не все страницы удается сжать и сам процесс занимает некоторое время. Поэтому данная техника на практике не очень эффективна.

Memory Swapping. После недолгой фазы Memory Compression ESXi практически неизбежно (если ВМ не уехали на другие хосты или не выключились) переходит к Swapping’у. А если памяти осталось совсем мало (состояние Low), то гипервизор также перестает выделять ВМ страницы памяти, что может вызвать проблемы в гостевых ОС ВМ.

Вот как работает Swapping. При включении виртуальной машины для нее создается файл с расширением .vswp. По размеру он равен незарезервированной оперативной памяти ВМ: это разница между сконфигурированной и зарезервированной памятью. При работе Swapping’а ESXi выгружает страницы памяти виртуальной машины в этот файл и начинает работать с ним вместо физической памяти сервера. Разумеется, такая такая “оперативная” память на несколько порядков медленнее настоящей, даже если .vswp лежит на быстром хранилище.

В отличие от Ballooning’а, когда у ВМ отбираются неиспользуемые страницы, при Swapping’e на диск могут переехать страницы, которые активно используются ОС или приложениями внутри ВМ. В результате производительность ВМ падает вплоть до подвисания. ВМ формально работает и ее как минимум можно правильно отключить из ОС. Если вы будете терпеливы ;)

Если ВМ ушли в Swap — это нештатная ситуация, которую по возможности лучше не допускать.

Основные счетчики производительности памяти виртуальной машины

Вот мы и добрались до главного. Для мониторинга состояния памяти в ВМ есть следующие счетчики:

Active — показывает объем оперативной памяти (Кбайт), к которому ВМ получила доступ в предыдущий период измерения.

Usage — то же, что Active, но в процентах от сконфигурированной оперативной памяти ВМ. Рассчитывается по следующей формуле: active ÷ virtual machine configured memory size.
Высокий Usage и Active, соответственно, не всегда является показателем проблем производительности ВМ. Если ВМ агрессивно использует память (как минимум, получает к ней доступ), это не значит, что памяти не хватает. Скорее это повод посмотреть, что происходит в ОС.
Есть стандартный Alarm по Memory Usage для ВМ:

Shared — объем оперативной памяти ВМ, дедуплицированной с помощью TPS (внутри ВМ или между ВМ).

Granted — объем физической памяти хоста (Кбайт), который был отдан ВМ. Включает Shared.

Consumed (Granted — Shared) — объем физической памяти (Кбайт), которую ВМ потребляет с хоста. Не включает Shared.

Если часть памяти ВМ отдается не из физической памяти хоста, а из swap-файла или память отобрана у ВМ через Balloon Driver, данный объем не учитывается в Granted и Consumed.
Высокие значения Granted и Consumed — это совершенно нормально. Операционная система постепенно забирает память у гипервизора и не отдает обратно. Со временем у активно работающей ВМ значения данных счетчиков приближается к объему сконфигурированной памяти, и там остаются.

Zero — объем оперативной памяти ВМ (Кбайт), который содержит нули. Такая память считается гипервизором свободной и может быть отдана другим виртуальным машинам. После того, как гостевая ОС получила записала что-либо в зануленную память, она переходит в Consumed и обратно уже не возвращается.

Reserved Overhead — объем оперативной памяти ВМ, (Кбайт) зарезервированный гипервизором для работы ВМ. Это небольшой объем, но он обязательно должен быть в наличии на хосте, иначе ВМ не запустится.

Balloon — объем оперативной памяти (Кбайт), изъятой у ВМ с помощью Balloon Driver.

Compressed — объем оперативной памяти (Кбайт), которую удалось сжать.

Swapped — объем оперативной памяти (Кбайт), которая за неимением физической памяти на сервере переехала на диск.
Balloon и остальные счетчики memory reclamation techniques равны нулю.

Вот так выглядит график со счетчиками Memory нормально работающей ВМ со 150 ГБ оперативной памяти.

На графике ниже у ВМ явные проблемы. Под графиком видно, что для данной ВМ были использованы все описанные техники работы с оперативной памятью. Balloon для данной ВМ сильно больше, чем Consumed. По факту ВМ скорее мертва, чем жива.

ESXTOP

Как и с CPU, если хотим оперативно оценить ситуацию на хосте, а также ее динамику с интервалом до 2 секунд, стоит воспользоваться ESXTOP.

Экран ESXTOP по Memory вызывается клавишей «m» и выглядит следующим образом (выбраны поля B,D,H,J,K,L,O):

Интересными для нас будут следующие параметры:

Mem overcommit avg — среднее значение переподписки по памяти на хосте за 1, 5 и 15 минут. Если выше нуля, то это повод посмотреть, что происходит, но не всегда показатель наличия проблем.

В строках PMEM/MB и VMKMEM/MB — информация о физической памяти сервера и памяти доступной VMkernel. Из интересного здесь можно увидеть значение minfree (в МБайт), состояние хоста по памяти (в нашем случае, high).

В строке NUMA/MB можно увидеть распределение оперативной памяти по NUMA-нодам (сокетам). В данном примере распределение неравномерное, что в принципе не очень хорошо.

Далее идет общая статистика по серверу по memory reclamation techniques:

PSHARE/MB — это статистика TPS;

SWAP/MB — статистика использования Swap;

ZIP/MB — статистика компрессии страниц памяти;

MEMCTL/MB — статистика использования Balloon Driver.

По отдельным ВМ нас может заинтересовать следующая информация. Имена ВМ я скрыл, чтобы не смущать аудиторию:). Если метрика ESXTOP аналогична счетчику в vSphere, привожу соответствующий счетчик.

MEMSZ — объем памяти, сконфигурированный на ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted в МБайт.

TCHD — Active в МБайт.

MCTL? — установлен ли на ВМ Balloon Driver.

MCTLSZ — Balloon в МБайт.

MCTLGT — объем оперативной памяти (МБайт), который ESXi хочет изъять у ВМ через Balloon Driver (Memctl Target).

MCTLMAX — максимальный объем оперативной памяти (МБайт), который ESXi может изъять у ВМ через Balloon Driver.

SWCUR — текущий объем оперативной памяти (МБайт), отданный ВМ из Swap-файла.

SWGT — объем оперативной памяти (МБайт), который ESXi хочет отдавать ВМ из Swap-файла (Swap Target).

Также через ESXTOP можно посмотреть более подробную информацию про NUMA-топологию ВМ. Для этого нужно выбрать поля D,G:

NHN – NUMA узлы, на которых расположена ВМ. Здесь можно сразу заметить wide vm, которые не помещаются на один NUMA узел.

NRMEM – сколько мегабайт памяти ВМ берет с удаленного NUMA узла.

NLMEM – сколько мегабайт памяти ВМ берет с локального NUMA узла.

N%L – процент памяти ВМ на локальном NUMA узле (если меньше 80% — могут возникнуть проблемы с производительностью).

Memory на гипервизоре

Если счетчики CPU по гипервизору обычно не представляют особого интереса, то с памятью ситуация обратная. Высокий Memory Usage на ВМ не всегда говорит о наличие проблемы с производительностью, а вот высокий Memory Usage на гипервизоре, как раз запускает работу техник управления памятью и вызывает проблемы с производительностью ВМ. За алармами Host Memory Usage надо следить и не допускать попадания ВМ в Swap.

Unswap

Если ВМ попала в Swap, ее производительность сильно снижается. Следы Ballooning’а и компрессии быстро исчезают после появления свободной оперативной памяти на хосте, а вот возвращаться из Swap в оперативную память сервера виртуальная машина совсем не торопится.
До версии ESXi 6.0 единственным надежным и быстрым способ вывода ВМ из Swap была перезагрузка (если точнее выключение/включение контейнера). Начиная с ESXi 6.0 появился хотя и не совсем официальный, но рабочий и надежный способ вывести ВМ из Swap. На одной из конференций мне удалось пообщаться с одним из инженеров VMware, отвечающим за CPU Scheduler. Он подтвердил, что способ вполне рабочий и безопасный. В нашем опыте проблем с ним также замечено не было.

Собственно команды для вывода ВМ из Swap описал Duncan Epping. Не буду повторять подробное описание, просто приведу пример ее использования. Как видно на скриншоте, через некоторое время после выполнения указанной команд Swap на ВМ исчезает.

Советы по управлению оперативной памятью на ESXi

Напоследок приведу несколько советов, которые помогут вам избежать проблем с производительностью ВМ из-за оперативной памяти:

Немного теории

Какие техники применять ESXi решает в зависимости от загруженности оперативной памяти:

Состояние памяти	Граница	Действия
High	400% от minFree	После достижения верхней границы, большие страницы памяти разбиваются на маленькие (TPS работает в стандартном режиме).
Clear	100% от minFree	Большие страницы памяти разбиваются на маленькие, TPS работает принудительно.
Soft	64% от minFree	TPS + Balloon
Hard	32% от minFree	TPS + Compress + Swap
Low	16% от minFree	Compress + Swap + Block

minFree — это оперативная память, необходимая для работы гипервизора.

Значение minFree (по умолчанию) считается следующим образом:

Процент памяти, резервируемый для minFree	Диапазон памяти
6%	0-4 Гбайт
4%	4-12 Гбайт
2%	12-28 Гбайт
1%	Оставшаяся память

Процент памяти, резервируемый для minFree	Диапазон памяти	Значение для 128 Гбайт
6%	0-4 Гбайт	245,76 Мбайт
4%	4-12 Гбайт	327,68 Мбайт
2%	12-28 Гбайт	327,68 Мбайт
1%	Оставшаяся память (100 Гбайт)	1024 Мбайт

Источник

Работу Balloon Driver’а можно проверить из ОС через VMware Tools.

Если ВМ ушли в Swap — это нештатная ситуация, которую по возможности лучше не допускать.

Основные счетчики производительности памяти виртуальной машины

Вот мы и добрались до главного. Для мониторинга состояния памяти в ВМ есть следующие счетчики:

Shared — объем оперативной памяти ВМ, дедуплицированной с помощью TPS (внутри ВМ или между ВМ).

Granted — объем физической памяти хоста (Кбайт), который был отдан ВМ. Включает Shared.

Consumed (Granted — Shared) — объем физической памяти (Кбайт), которую ВМ потребляет с хоста. Не включает Shared.

Balloon — объем оперативной памяти (Кбайт), изъятой у ВМ с помощью Balloon Driver.

Compressed — объем оперативной памяти (Кбайт), которую удалось сжать.

Вот так выглядит график со счетчиками Memory нормально работающей ВМ со 150 ГБ оперативной памяти.

ESXTOP

Экран ESXTOP по Memory вызывается клавишей «m» и выглядит следующим образом (выбраны поля B,D,H,J,K,L,O):

Интересными для нас будут следующие параметры:

Далее идет общая статистика по серверу по memory reclamation techniques:

PSHARE/MB — это статистика TPS;

SWAP/MB — статистика использования Swap;

ZIP/MB — статистика компрессии страниц памяти;

MEMCTL/MB — статистика использования Balloon Driver.

MEMSZ — объем памяти, сконфигурированный на ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted в МБайт.

TCHD — Active в МБайт.

MCTL? — установлен ли на ВМ Balloon Driver.

MCTLSZ — Balloon в МБайт.

MCTLGT — объем оперативной памяти (МБайт), который ESXi хочет изъять у ВМ через Balloon Driver (Memctl Target).

MCTLMAX — максимальный объем оперативной памяти (МБайт), который ESXi может изъять у ВМ через Balloon Driver.

SWCUR — текущий объем оперативной памяти (МБайт), отданный ВМ из Swap-файла.

SWGT — объем оперативной памяти (МБайт), который ESXi хочет отдавать ВМ из Swap-файла (Swap Target).

NRMEM – сколько мегабайт памяти ВМ берет с удаленного NUMA узла.

NLMEM – сколько мегабайт памяти ВМ берет с локального NUMA узла.

Memory на гипервизоре

Unswap

Советы по управлению оперативной памятью на ESXi

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Если вы зайдете в настройки ВМ ^ закладка Resources, то увидите настройки ресурсов для этой ВМ. Выделим настройки памяти (рис. 6.3).

На первый взгляд, все точно так же, как и для процессора, но есть нюанс.

Рис. 6.3. Настройки ресурсов для памяти ВМ

Limit - это максимальное количество мегабайт, которое может быть выделено для этой ВМ. Но что означает стоящий по умолчанию флажок Unlimited?

И что за память тогда настраивается на закладке Hardware (рис. 6.4)?

Рис. 6.4. Настройка «Hardware» памяти Что означает Reservation, если гостевая ОС в любом случае видит весь выделенный ей объем памяти?

С памятью ситуация следующая.

Верхней границей, то есть количеством памяти, которое видит гостевая ОС, является настройка памяти на закладке Hardware. Я ее в дальнейшем буду называть «hardware memory», и такое название вам может встретиться в документации. Таким образом, если вы хотите ограничить ВМ сверху, меняйте не настройку Limit, а количество памяти на закладке Hardware.

Reservation - столько мегабайт памяти гарантированно выделяется из физической оперативной памяти. Все, что больше резерва, может быть выделено из файла подкачки.

Limit - больше этого количества мегабайт не будет выделено из физической оперативной памяти. Остаток до hardware memory обязательно будет выдан из файла подкачки, даже если на сервере нет недостатка в свободной оперативной памяти.

Скорее всего, вы не будете использовать настройку Limit на уровне ВМ. Если вам необходимо выделить для ВМ меньше памяти - уменьшайте значение настройки Hardware memory. Ситуаций, в которых вам может потребоваться изменение настройки Limit, немного. Например, стоит задача протестировать приложение Х, у которого жесткие системные требования, и оно отказывается запускаться, если считает, что компьютер им не удовлетворяет (у него меньше А гигабайт ОЗУ). Если у сервера ESX(i) мало ресурсов, то можно настройкой hardware memory указать достаточное для запуска приложения X количество памяти. А настройкой Limit ограничить реальное потребление оперативной памяти сервера этой ВМ. Или, как вариант, вы сейчас не хотите выделять какой-то ВМ много памяти, но в будущем это может понадобиться. Для увеличения Hardware memory требуется выключение ВМ (за исключением случая использования тех гостевых ОС, которые поддерживают горячее добавление памяти), для увеличения Limit - нет.

Shares. Однако как быть в ситуации, когда ресурсов сервера достаточно для покрытия резервов всех работающих ВМ, однако недостаточно для удовлетворения их аппетитов (и они не уперлись в свои лимиты)? В таких ситуациях работает настройка Shares («доля»). Какую долю составляет количество shares одной ВМ относительно суммы shares всех претендующих на ресурс ВМ - такую долю этого ресурса ВМ и получит. Shares - это именно доля, это безразмерная величина. Обратите внимание: если для процессора константы Low, Normal и High соответствуют 500, 1000 или 2000 shares на ВМ, то для памяти это не так. Для памяти Low, Normal или High соответствуют 5, 10 или 20 shares на каждый мегабайт памяти ВМ.

Пример: на сервере оказались три ВМ. Объем памяти у двух равен 500 Мб, у третьей - 1000 Мб. Shares у них одинаковый, Normal, то есть по 10 на мегабайт. См. рис. 6.5.

Всего shares 20 000. Виртуальные машины А и Б имеют право на до четверти от всей памяти. ВМ В - на половину, при такой же настройке shares. И это логично, так как аппетиты ВМ В вдвое выше каждой из прочих.

Рис. 6.5. Описание примера распределения долей памяти Еще раз напомню - механизм shares работает, когда ВМ:

- уже превысила свой резерв;

- еще не достигла своего лимита;

- памяти не хватает на все претендующие на нее ВМ.

Если для какой-то ВМ увеличить или уменьшить shares, ей немедленно увеличат или уменьшат долю ресурса, выключения ВМ для этого не требуется.

Обратите внимание: если ВМ не задействует память - ESX(i) не адресует ее для этой ВМ. Посмотреть это можно на закладке Summary для виртуальной машины (рис. 6.6).

Рис. 6.6. Информация об объемах выделенной и используемой памяти Выделена настройка Memory = 1 Гб. Столько памяти видит гостевая ОС, это настройка «Hardware memory». Справа показана «Active Guest Memory» - столько памяти активно использует гостевая ОС. А «Consumed Host Memory» показывает, сколько физической памяти ESX(i) выделил под данные этой ВМ. В упрощенной формулировке это означает, что ESX(i) может уменьшить Consumed Memory до Active Memory при необходимости, без ущерба для производительности ВМ.

Если выделить пул ресурсов, vApp, сервер, кластер или дата-центр и перейти на закладку Virtual Machines, то подобную информацию можно получить для всех ВМ выделенного объекта (рис. 6.7).

Рис. 6.7. Данные по использованию памяти для всех ВМ на одном сервере По умолчанию вы увидите не совсем тот же набор столбцов. Это настраивается в контекстном меню данной закладки ^ View Column.

Столбец Memory Size - это «hardware memory». Столбец Guest Mem % - какой процент от выделенной памяти активно использует гостевая ОС.

Если у сервера недостаточно памяти для удовлетворения резерва ВМ, то эта ВМ не включится. Если у сервера недостаточно памяти для удовлетворения аппетитов ВМ сверх резерва - то недостаток физической оперативной памяти будет компенсирован файлом подкачки. Механизмов подкачки используется два - файл подкачки гостевой ОС и файл подкачки VMkernel, создаваемый для каждой виртуальной машины при ее включении. Дальше про эти механизмы я расскажу чуть подробнее, здесь же хочу отметить - при включении ВМ создается файл .vswp. Именно в этот файл ESX(i) адресует часть памяти ВМ, если памяти физической не хватает. Как велика эта часть? В наихудшем случае это вся память сверх резерва до hardware memory. Размер файла подкачки как раз такой: «hardware memory» минус reservation. Таким образом, если оставить reservation равным нулю, при включении каждой ВМ создается файл размером с ее оперативную память. Выводов отсюда два:

- если на хранилище для файлов подкачки (по умолчанию файл подкачки создается в каталоге ВМ) недостаточно места для создания этого файла -ВМ не включится;

- если вам необходимо освободить сколько-то места на разделах VMFS, один из способов - это увеличение reservation для памяти ВМ: чем больше резерв, тем меньше места резервируется под файл .vswp, файл подкачки VMkernel (альтернатива этому - расположение файлов подкачки VMker-nel на отдельном хранилище).

Читайте также: