Vswp vmware что это
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Limit, shares, reservation - это настройки, которыми мы указываем, как распределять ресурсы. А теперь поговорим о том, благодаря каким механизмам ESX(i) умеет эти настройки претворять в жизнь и как устроено распределение ресурсов сервера между виртуальными машинами.
С точки зрения ESX(i) процессоры бывают трех типов:
- физические (physical, PCPU). Это именно процессоры, иногда говорят «сокеты». В зависимости от их количества ESX(i) лицензируется;
- логические (logical, LCPU). Это ядра физического процессора. Физические ядра или, в случае hypertreading, ядра логические. Каждый LCPU - это одна очередь команд;
- виртуальные (virtual, VCPU). Один vCPU - это один процессор виртуальной машины. Напомню, что процессоров на виртуальную машину может быть до восьми.
Самое первое, что необходимо сказать:
- один vCPU работает на одном LCPU. То есть виртуальная машина с одним виртуальным процессором работает на одном ядре. То есть даже если у вас однопроцессорный восьмиядерный сервер, на котором работает только одна ВМ с одним процессором, - она задействует только одно ядро;
- а вот если эта ВМ с восемью vCPU, то она задействует все восемь ядер -ESX(i) в обязательном порядке разводит по разным ядрам процессоры одной ВМ;
- на одном ядре может выполняться несколько vCPU разных виртуальных машин (рис. 6.23).
Рис. 6.23. Иллюстрация работы с процессорной подсистемой Источник: VMware
На иллюстрации показан двухпроцессорный сервер, каждый процессор двухъядерный.
Гипервизор осуществляет балансировку нагрузки, с интервалом в 20 миллисекунд может переносить vCPU между LCPU для лучшей их утилизации. Service Console всегда работает на CPU0, то есть первом ядре первого процессора.
Обратите внимание. Если сервер построен на архитектуре NUMA, то гипервизор будет это учитывать и пытаться располагать все vCPU одной ВМ на одном процессоре. Избегайте создавать ВМ с числом vCPU, большим, чем число ядер одного процессора на серверах с архитектурой NUMA. В последнем случае гипервизор будет вынужден vCPU одной виртуальной машины выполнять на ядрах разных процессоров, что замедлит доступ к памяти.
Из тех же соображений не стоит выдавать для виртуальной машины памяти больше, чем локально доступно одному процессору физического сервера. Определить эту величину можно, например, с помощью esxtop, счетчика NUMA.
Операционная система ожидает, что все ее процессоры будут работать одновременно. В случае физических серверов так и происходит. Но в случае виртуализации процессоры, видимые гостевой ОС, являются виртуальными процессорами, которыми управляет гипервизор. В частности, гипервизор перераспределяет ресурсы физических процессоров (ядер) между многими процессорами виртуальными. И именно из-за того, что на каждом физическом ядре работают несколько виртуальных процессоров, гипервизору и неудобно выделять такты виртуальным процессорам одной ВМ одновременно (ведь нагрузка на разные физические ядра разная, где-то в данный момент есть свободные такты, где-то нет). А если выделять их не одновременно, то гостевые ОС как минимум будут получать пенальти по производительности, а как максимум - падать в BSOD и Kernel panic.
Для гипервизоров предыдущих поколений эта проблема решалась тем, что гипервизор отслеживал «рассинхронизацию», то есть ситуацию, когда какие-то vCPU работали, а какие-то нет. Когда разница во времени работы достигала порогового значения (несколько миллисекунд), гипервизор останавливал «убежавшие вперед» vCPU и ждал возможности выделить процессорные такты всем vCPU этой ВМ одновременно. Получалось, что значительную долю времени все несколько vCPU этой ВМ простаивали. Так поступал ESX версии 2.
Однако ESX(i), начиная еще с версии 3, использует механизм под названием «Relaxed coscheduling». Суть его заключается в том, что одновременно получать такты должны не все vCPU одной ВМ, а лишь те, что «отстали». Это уменьшает потери производительности из-за виртуализации, позволяя более эффективно утилизировать процессорные ресурсы сервера.
Однако панацеей такой механизм не является, поэтому следует стремиться настраивать для виртуальных машин так мало vCPU, как это возможно с точки зрения производительности.
Обратите внимание. Консольная утилита esxtop (resxtop для vCLI) показывает время ожидания синхронизации в столбце %CSTP. Таким образом, эта величина характеризует накладные расходы на виртуализацию процессоров многопроцессорной ВМ.
Также в свойствах ВМ на закладке Resources есть строка Advanced CPU (рис. 6.24).
Здесь вы можете задать настройки Hyperthreaded Core Sharing и CPU Affinity.
Рис. 6.24. Настройки Advanced CPU
Hyperthreaded Core Sharing управляет тем, как будут использоваться логические процессоры, на которые делится каждое физическое ядро при включении гипертрейдинга. Напомню, что для процессоров с включенным гипертрейдингом каждое физическое ядро порождает два логических, что теоретически позволяет выполнять часть команд в два потока.
- Any - когда виртуальный процессор этой ВМ работает на каком-то ядре, то на втором логическом ядре этого физического ядра могут работать другие vCPU этой и других виртуальных машин;
- Internal - настройка доступна лишь для многопроцессорных виртуальных машин. Когда ВМ с несколькими vCPU, то они могут работать на разных логических ядрах одного физического ядра. Для ВМ с одним процессором такое значение этой настройки эквивалентно значению None;
- None - когда vCPU этой ВМ начинает выполняться на каком-то физическом ядре, то он захватывает его полностью. Второе логическое ядро простаивает. На данном ядре выполняется только этот один vCPU этой одной ВМ.
Обратите внимание: эта настройка сбрасывается на значение по умолчанию (Any), когда ВМ в DRS-кластере или при миграции ВМ на другой сервер. Применимость этой настройки невелика - лишь для тонкого тюнинга производительности виртуальных машин на одном сервере. Как правило, ESX(i) хорошо управляет распределением ресурсов без нашего участия.
Обратите внимание. Нет четких данных по эффективности использования гипертрейдинга для ESX(i). Как правило, от включения гипертрейдинга производительность меняется незначительно. Вероятность ухудшения производительности от включения этой функции невелика.
Scheduling Affinity - здесь мы можем указать ядра, на которых могут выполняться vCPU этой ВМ. Если по умолчанию гипервизор может расположить процессор ВМ на любом ядре, то с помощью этой настройки мы можем ограничить его выбор.
Если мы изменили данную настройку со значения по умолчанию, то ВМ теряет способность к живой миграции, что значительно снижает применимость данной настройки.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- VMware Technology Network
- :
- Cloud & SDDC
- :
- ESXi
- :
- ESXi Discussions
- :
- what is xxx.vswp file what is for?
hihiy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
waht is .vswp file, and what is for?
Rubeck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
The vswp file is used if the physical host is out of memory, and is basically what makes overcommitment of memory possible.
The .vswp file belongs to a VM. By default these are placed in each home dir. of any VM. This is per default the same size as the memory assigned for the VM unless you do reservations. If you do a 512MB memory reservation on a VM which has 2048MB assigned, the vswp file will then only be 1536MB..
Rubeck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
The vswp file is used if the physical host is out of memory, and is basically what makes overcommitment of memory possible.
The .vswp file belongs to a VM. By default these are placed in each home dir. of any VM. This is per default the same size as the memory assigned for the VM unless you do reservations. If you do a 512MB memory reservation on a VM which has 2048MB assigned, the vswp file will then only be 1536MB..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
as stated it is a guest swap file. it's the last resort for the hypervisor when it can't allocate enough memory for the guest.
VMware Communities User Moderator | VCP | VCDX
sabya1232003
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
As explained ..this file is required when there is a resource crunch for the Host's physical memory.The VMkernel tries to use this space for the required memory of the VM.This can be considered as the similar kind of role as the page file or swap file for Windows/Linux OS when there is a requirement
Начнём с того, что есть два типа свапинга, которые могут происходить на 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 — это нештатная ситуация, которую по возможности лучше не допускать.
Основные счетчики производительности памяти виртуальной машины
Вот мы и добрались до главного. Для мониторинга состояния памяти в ВМ есть следующие счетчики:
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
Напоследок приведу несколько советов, которые помогут вам избежать проблем с производительностью ВМ из-за оперативной памяти:
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 на отдельном хранилище).
Читайте также: