Virtual machine memory usage vmware ошибка - Не ошибается лишь тот, кто ничего не делает!

Hi Guys,

How are you doing? thanks for the Kind assist…I have a warning error that wont go away on our Vsphere web client about the Virtual machine host memory usage. Please does anybody has a clue as to what the warning could be? My take on it is either something is spiking the memory or I might need to add more Physical memory to the host. I´m just tried of acknowledging the warning and then it shows up again,any tip is appreciated.

attach_file
Attachment

2017-09-22_15_44_…Client.png
24.2 KB

Источник

Обновлено 27.06.2017

Добрый день уважаемые читатели и подписчики, продолжаем изучать виртуализацию и гипервизор компании VMware. В прошлый раз я вам рассказывал, как установить wmware tools в linux, сегодняшняя тема будет, так же про ошибки и предупреждения и разберем мы с вами вот такие «host CPU usage и host memory usage», что это такое и чем это чревато для вашей инфраструктуры.

Предупреждения о ОЗУ и CPU

Данные предупреждения и алерты, вы можете обнаружить как в vCenter server, так и на отдельном хосте ESXI. Выглядят эти алерты вот так:

Host memory usage на вкладке Alarms

Host CPU usage на вкладке Alarms

Оба этих предупреждений на самом деле очень критичные, так как сообщают, что ваш ESXI хост использует всю или практически всю оперативную память или процессор, хорошо если это небольшая пиковая нагрузка, но если такая ситуация постоянная, есть повод серьезно задуматься над выделенными ресурсами (я уже высказывал свои мысли по этому поводу)

Если вы перейдет на вкладку «Summary», то в пункте «Resources» увидите шкалу загрузки по процессору

и оперативной памяти.

Пути решения данной ситуации такие:

Вы ограничиваете потребление ресурсов для прожорливой виртуальной машины
Либо более правильно перераспределяете их и дорабатываете план планирования, это дольше, но лучше, так как будет возможность предусмотреть будущий рост

Что плохого несут в себе эти предупреждения

Если у вас появились сообщения «Host CPU usage и host memory usage», это чревато тем что:

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

Советую к этим моментам отнестись более детально, от себя могу порекомендовать хорошую статью, про использовании памяти виртуальными машинами VMware vSphere и не доводите до такого.

Июн 27, 2017 10:20

Источник

Virtual Machine(VM) Itself Tells me it is Using Almost All my Mac’s RAM!!!

As shown below, I received an error message stating that my VM is currently using too much memory, basically recommending to put aside what was being performed.

What I was doing was installing 172 updates along with 7 optional updates. This is a completely-new VM: one of Windows 7 Professional.

To suspend this, I have shut down the VM; closed VMWare Fusion; have close VMWare Fusion; and have now completely shut down my Mac for the time being.

The message was within the VM itself, being a window of Microsoft’s OS GUI. The message therefore was non-maneuverable out side of it.

Was the RAM message referring to only the RAM assigned to the VM? Or was the message referring to the Mac’s total 32GB RAM? There is 32GB of RAM in my Mac, and the VM is only 60GB in size (My Mac has 1TB in SSD storage capacity).

How much RAM would be being used by a 60GB size VM? Almost all 32GB of the Mac?

———

For Note:

A Link on This: Memory usage alarm triggers for certain types of Virtual Machines in ESXi 6.x (2149787): https://kb.vmware.com/s/article/2149787

No suggestion is provided, as to what determines who’s RAM was being used: the VM or the Mac’s

— A similar error message found, word-for-word

Источник

We have seen the VMware ESXi host memory usage alarm in the vSphere console many times during the operations. Today we will discuss what course of action can be taken to remediate this issue.

The ESXi host memory usage go to high when the hosted Virtual Machines utilize higher memory than usual may be during specific job like backup job.

You can clear the alarm or monitor it. It will come to normal stage after sometimes. Alternatively you can either increase the RAM size of that esxi host or add more host in the cluster to balance the resource utilization.

How to clear the Alarm

To clear warnings and errors from the Hardware Status tab:

Go to the Hardware Status tab.
Click the System event log view.
Click Reset event log.
Click Update. The error clears.
Click the Alerts and warnings view.
Click Reset sensors.
Click Update. The memory clears.

Virtual machine memory

We can work with the virtual machine also. A virtual machine’s memory size must be slightly larger than the average guest memory usage. This enables the host to accommodate workload spikes without swapping memory among guests. Increasing the virtual machine memory size results in more overhead memory usage.

If sufficient swap space is available, a high balloon value does not cause performance problems. However, if the swapin and swapout values for the host are large, the host is probably lacking the amount of memory required to meet the demand.

If a virtual machine has high ballooning or swapping, check the amount of free physical memory on the host. A free memory value of 6% or less indicates that the host cannot meet the memory requirements. This leads to memory reclamation, which might degrade performance. If the active memory size is the same as the granted memory size, demand for memory is greater than the memory resources available. If the active memory is consistently low, the memory size might be too large.

If the host has enough free memory, check the resource shares, reservation, and limit of the virtual machines and resource pools on the host. Verify that the host settings are adequate and not lower than those set for the virtual machine.

If little free memory is available, or if you notice degradation in performance, consider taking the following actions.

Verify that VMware Tools is installed on each virtual machine. The balloon driver is installed with VMware Tools and is critical to performance.
Verify that the balloon driver is enabled. The VMkernel regularly reclaims unused virtual machine memory by ballooning and swapping. Generally, this does not impact virtual machine performance.
Reduce the memory space on the virtual machine, and correct the cache size if it is too large. This frees up memory for other virtual machines.
If the memory reservation of the virtual machine is set to a value much higher than its active memory, decrease the reservation setting so that the VMkernel can reclaim the idle memory for other virtual machines on the host.
Migrate one or more virtual machines to a host in a DRS cluster.
Add physical memory to the host.

This way you will be able to resolve the issue of VMware host memory usage.

Also Read,

All About VMware vSAN HCL Database Update – TechyGuy
VMware vSAN Features By Version Matrix – TechyGuy
All You Need To Know About VMware vSAN | vSAN 6.7 – TechyGuy
How to force shutdown VMware Virtual Machine – Techy Guy
VMware KB Article

Источник

Часть 1. Про CPU
Часть 3. Про Storage

В этой статье поговорим про счетчики производительности оперативной памяти (RAM) в vSphere.
Вроде бы с памятью все более однозначно, чем с процессором: если на ВМ возникают проблемы с производительностью, их сложно не заметить. Зато если они появляются, справиться с ними гораздо сложнее. Но обо всем по порядку.

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

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

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

Источник

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

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

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

Источник

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

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

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

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

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

Источник

Данный механизм работает только для страниц памяти размером 4 Кбайт (small pages). Страницы размером 2 МБайт (large pages) гипервизор дедуплицировать даже не пытается: шанс найти одинаковые страницы такого размера не велик.

По умолчанию 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

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

Не допускайте переподписки по оперативной памяти в продуктивных кластерах. Желательно всегда иметь ~20-30% свободной памяти в кластере, чтобы у DRS ( и у администратора) было пространство для маневра, и при миграции ВМ не ушли в Swap. Также не забывайте про запас для отказоустойчивости. Неприятно, когда при выходе из строя одного сервера и перезагрузке ВМ с помощью HA часть машин еще и уходит в Swap.
В инфраструктурах с высокой консолидацией старайтесь НЕ создавать ВМ с памятью больше половины памяти хоста. Это опять же поможет DRS’у без проблем распределять виртуальные машины по серверам кластера. Это правило, разумеется, не универсальное :).
Следите за Host Memory Usage Alarm.
Не забывайте ставить на ВМ VMware Tools и не выключайте Ballooning.
Рассмотрите возможность включения Inter-VM TPS и выключения Large Pages в средах с VDI и тестовых средах.
Если ВМ испытывает проблемы с производительностью, проверьте не использует ли она память с удаленной NUMA-ноды.
Выводите ВМ из Swap как можно быстрее! Помимо всего прочего, если ВМ в Swap’е, по очевидным причинам страдает СХД.

На этом про оперативную память у меня все. Ниже статьи по теме для тех, кто хочет углубиться в детали. Следующая статья будет посвящена стораджу.

Источник