Guest mem vmware что это
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Hommer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Can someone please explain to me what the difference is between Host Mem - MB and Guest Mem - % is when I view the Virtual Machine under the VC console.
I have 3 VM each with 2048MB allocated and the ESX server has 16GB of RAM. The 3 VM shows the following entries
VM1, Host CPU Mhz 122, Host Mem - MB 1259, Guest Mem - % 11
VM2, Host CPU Mhz 71, Host Mem - MB 910 , Guest Mem - % 6
VM3, Host CPU Mhz 37, Host Mem - MB 396, Guest Mem - % 4
All VMs have the latest VM Tools installed
Do these numbers looks right?
esiebert7625
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Vmware support pointed me to the below posts which explain it pretty good if you read through all the other post references in them.
jurajfox
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
I've wondered about that too. The host memory usage seems more straighforward - that's the amount of memory that is being taken up by the VM out of it's total allocated.
esiebert7625
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Host Mem MB is the amount of physical RAM a VM is currently using on the ESX host. This will vary based on ESX's memory saving techniques and the amount of memory usage by the VM.
Guest Mem % is the total percentage of memory that a VM is using based on it's total memory. So if a VM has 1GB of memory and is only using 256MB then it would be 25%
These are 2 great memory docs.
esiebert7625
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
To elaborate further:
VM1, Host CPU Mhz 122, Host Mem - MB 1259, Guest Mem - % 11
This VM has 2GB assigned to it, the OS is only using 11% or about 225KB of memory assigned to it. The reason it is using 1259MB of physical host memory is probably because the memory balloon on the OS that is part of Vmware Tools is inflated to preserve memory for the VM. The memory balloon will inflate and deflate based on trends inside the VM operating system. Depending on how long these VM's have been powered on this number will start higher and gradually decrease. VM's initially show high host mem and guest mem % which will decrease over time.
This is common when a virtual machine first boots. Windows zeroes the contents of all pages in physical memory while booting. This causes the system to become overcommitted almost immediately, as each VM accesses all of its memory. Since the Windows balloon drivers are not started until late in the boot sequence, ESX Server is forced to start paging to disk. Soon after booting the amount of shared memory drops rapidly, and ESX Server compensates by using ballooning to reclaim memory. Page sharing continues to exploit sharing opportunities over time saving additional memory.
Начнём с того, что есть два типа свапинга, которые могут происходить на ESXi хосте. Их очень часто путают, поэтому давайте условно будем называть их Тип 1 и Тип 2.
Расположение данных VMware ESXi по умолчанию
Тип 1. VMX swapping (vSwap)
Это самый простой тип свапинга для описания. Память выделяется не только для виртуальных машин, а также и для различных компонент хоста, к примеру, для монитора виртуальных машин (VMM) и виртуальных устройств. Такая память может быть свапирована для того, чтобы выделить более нуждающимся виртуальным машинам больше физической памяти. По словам VMware эта возможность может высвободить от 50MB до 10MB памяти, для каждой виртуальной машины без существенного ухудшения производительности.
Тип 2. Guest OS Swapping
ESXi Host swapping
vSwap (Тип 1) по умолчанию сохраняется в .vswp файл в папке с виртуальной машиной. NetApp рекомендует сохранять vSwap (Тип 1) на выделенный датастор.
Такой файл существует только для запущенных виртуальных машин – при запуске гипервизор создаёт этот файл и удаляет при выключении виртуальной машины. Обратите внимание на размер этого файла — он равен разнице между сконфигурированной памятью для виртуальной машины и резервом физической памяти за этой машиной. Таким образом обеспечивается наличие заданного пространства памяти, когда виртуальная машина стартует (не зависимо от того, какая память используется — настоящая физическая или vSwap). Резерв заботится о том, чтобы виртуальная машина получила нужное пространство всегда в физической памяти хоста. А разница между резервом и настроенной памятью виртуальной машины сохраняется в vswp файл.
Ниже пример запуска виртуальной машины с 4GB памяти и резервом 2GB. Помните, что vSwap удаляется после выключения? А если в этот момент датастор хранящий эту виртуальную машину заполнится и останется свободного 1.8GB пространства, что произойдёт?
Что можно с этим сделать? Конечно же можно высвободить пространство на датасторе или расположить vSwap (Тип 1) на другом датасторе. По умолчанию он хранится в папке с виртуальной пашиной. Если это «standalone» хост: Configuration > Software > Virtual Machine Swapfile Location. Расположение vSwap файлов также можно изменить на уровне настроек каждой виртуальной машины. Откройте настройки виртуальной машины и выберите вкладку Options:
Если этот хост часть кластера, загляните в настройки кластера Store the swapfile in the datastore specified by the host
Далее выберите датастор где будет храниться vSwap (Тип 1).
Зачем располагать свап на отдельный датастор?
Рекомендуемая схема расположения Swap'а для NetApp FAS
Во-первых стоит отметить что общее правило VMware гласит по возможности располагать vSwap (Тип 1) в папке с виртуальной машиной, так как вынесение на отдельный датастор может замедлить vMotion. Но в частном случае VMware + NetApp FAS вступает другая рекомендация. NetApp рекомендует хранить vSwap (Тип 1) на отдельном выделенном, одном для всех виртуальных машин датасторе, так как в этом случае разница при миграции vMotion практически нивелирована. VMware рекомендует, чтобы пространство под vSwap (Тип 1) было больше или равно разнице сконфигурированной и зарезервированной для виртуальной машины памяти. Иначе виртуальные машины могут не стартовать. Пример: у нас есть 5 виртуальных машин с размером памяти 4GB и резервацией для каждой 3GB.
Минимальный размер датастора для vSwap Тип 1:
5VM * (4 GB — 3GB )= 5GB
Если на хосте нет свободных физических 5VM * 3GB = 15 GB памяти, машины могут не стартовать, выводя ошибку:
The host does not have sufficient memory resources to satisfy the reservation
И в то же время будет создан Event log
Во-вторых это производительность – расположив свап на более медленном датасторе, если вы уверены, что свапинга почти никогда не будет. Или если виртуальные машины будут запрашивать больше памяти, чем есть на хосте, и свапинг будет постоянным – на более быстром датасторе.
В-третьих это снепшоты и дедубликация на уровне хранилища. Так как у нетапа снепшоты не влияют на производительность, они являются нормой жизни, выполняются постоянно и являются частью парадигмы резервного копирования NetApp для систем FAS. Свап это абсолютно бесполезная информация при резервном копировании и восстановлении. Если он интенсивно используется, а снепшоты часто снимаются, в снепшотах будет «захвачена» и храниться, все время жизни снепшота, эта бесполезная информация. А так как свап постоянно меняется, а спепшот захватывает только новые изменённые данные, в каждом таком снепшоте будет храниться эти новые изменённые данные из свапа, беспощадно поедая полезное пространство под бесполезные данные на хранилище. Дедублицировать свап нет никакого резона, ведь данные в свапе не нужны при восстановлении и никогда не будут считаны. В этом смысле удобно выносить свапы на отдельный датастор. NetApp рекомендует располагать свап на отдельный датастор с выключенными снепшотами и дедубликацией, так мы можем ещё сильнее уменьшить оверхед в снепшотах и на репликации.
NetApp не рекомендует использовать локальные диски (стр 76-78, DEC11) на хосте, для хранения vSwap (Тип 1) потому, что такая конфигурация имеет негативное влияние на скорость выполнения операции vMotion.
Стоит ли выносить Тип 2 Swap?
Размещение временных данных, таких как Swap и Pagefile.sys на выделенный датастор (создав выделенный виртуальный диск для этой цели) позволяет не дедублицировать и не бэкапировать эти данные также как и vSwap (Тип 1). Очень важно не забыть указать этот диск как Independent, чтобы агент VSC не заставлял FAS снимать снепшоты с раздела хранящего Swap файлы (Тип 2).
У NetApp нет рекомендаций относительно Swap Тип 2, вынесение этих данных является опциональным дизайном, у которого есть свои плюсы и минусы:
В дополнение к вынесенному vSwap Тип 1, вынесение Swap Тип 2 ещё сильнее уменьшит оверхед на снепшотах, и как следствие увеличит пропускную способность для репликации. В ACB для DR решений наличие Swap'а (оба типа) не нисет никакой смысловой нагрузки, ведь он не используется при старте системы. Если мы перестанем хранить Swap (Тип 2) в снепшотах и резервных копиях, при локальном восстановлении это не должно вызывать каких-либо проблем, так как восстанавливаемый .vmx config файл будет содержать ссылку на VMDK файл хранящий раздел со Swap'ом, ведь тот будет находиться на том же месте. Но это добавит дополнительные шаги при восстановлении на удалённой площадке, в таких конфигурациях как SRM , SnapProtect и других DR решений.
Опциональная схема расположения данных на NetApp FAS
Немного теории
Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, 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 — это нештатная ситуация, которую по возможности лучше не допускать.
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.
Что плохого несут в себе эти предупреждения
- Ваш сервер быстрее изнашивается, так как при правильно планировании, он не должен использовать более 90 процентов ресурсов.
- Идет борьба за ресурсы между виртуальными машинами, в следствии чего уменьшается их производительность.
- Может привести к зависанию хоста или виртуальной машины
Советую к этим моментам отнестись более детально, от себя могу порекомендовать хорошую статью, про использовании памяти виртуальными машинами VMware vSphere и не доводите до такого.
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 на отдельном хранилище).
Советы по управлению оперативной памятью на ESXi
Напоследок приведу несколько советов, которые помогут вам избежать проблем с производительностью ВМ из-за оперативной памяти:
Предупреждения о ОЗУ и CPU
Данные предупреждения и алерты, вы можете обнаружить как в vCenter server, так и на отдельном хосте ESXI. Выглядят эти алерты вот так:
Оба этих предупреждений на самом деле очень критичные, так как сообщают, что ваш ESXI хост использует всю или практически всю оперативную память или процессор, хорошо если это небольшая пиковая нагрузка, но если такая ситуация постоянная, есть повод серьезно задуматься над выделенными ресурсами (я уже высказывал свои мысли по этому поводу)
Если вы перейдет на вкладку "Summary", то в пункте "Resources" увидите шкалу загрузки по процессору
и оперативной памяти.
Пути решения данной ситуации такие:
- Вы ограничиваете потребление ресурсов для прожорливой виртуальной машины
- Либо более правильно перераспределяете их и дорабатываете план планирования, это дольше, но лучше, так как будет возможность предусмотреть будущий рост
Немного теории
Оперативная память виртуальных машин берется из памяти сервера, на которых работают ВМ. Это вполне очевидно:). Если оперативной памяти сервера не хватает для всех желающих, 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 — это нештатная ситуация, которую по возможности лучше не допускать.
Unswap
Если ВМ попала в Swap, ее производительность сильно снижается. Следы Ballooning’а и компрессии быстро исчезают после появления свободной оперативной памяти на хосте, а вот возвращаться из Swap в оперативную память сервера виртуальная машина совсем не торопится.
До версии ESXi 6.0 единственным надежным и быстрым способ вывода ВМ из Swap была перезагрузка (если точнее выключение/включение контейнера). Начиная с ESXi 6.0 появился хотя и не совсем официальный, но рабочий и надежный способ вывести ВМ из Swap. На одной из конференций мне удалось пообщаться с одним из инженеров VMware, отвечающим за CPU Scheduler. Он подтвердил, что способ вполне рабочий и безопасный. В нашем опыте проблем с ним также замечено не было.
Собственно команды для вывода ВМ из Swap описал Duncan Epping. Не буду повторять подробное описание, просто приведу пример ее использования. Как видно на скриншоте, через некоторое время после выполнения указанной команд 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. По факту ВМ скорее мертва, чем жива.
Читайте также: