memory ballooning что это такое

Memory ballooning что это такое

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в России Pyatilistnik.org. В прошлый раз мы с вами разобрали, почему процесс Software Reporter Tool грузит процессор на 100%. Сегодня я хочу поговорить про память в ESXI хостах и какого вида она бывает. Мы рассмотрим, что такое Memory Ballooning, разберем когда он включается и как он вам может помочь в безвыходной ситуации, до которой все же лучше не доводить.

Что такое Memory Ballooning?

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

Memory Ballooning включается когда у хост-сервера VMware ESX 6% или менее свободной памяти. Для изъятия памяти используются виртуальные машины, у которых больше всего памяти по процессу idle memory tax. Если сравнивать Ballooning и Swapping, то последний проигрывает примерно так (база данных Oracle в виртуальной машине для OLTP-нагрузок, т.е. постоянный поток небольших транзакций):

Когда включается Memory Ballooning в VMware vSphere-01

Помните да, что максимальный размер раздувающегося баллонного процесса можно задать глобально в Advanced Settings для всего хоста VMware vSphere:

Когда включается Memory Ballooning в VMware vSphere-02

Или локально в Advanced Settings виртуальной машины (то же самое, что и добавление строчки в vmx-файл конфигурации):

Кстати, в ESX 3.5 нам давали возможность изменить порог в 6%

Когда включается Memory Ballooning в VMware vSphere-03

Поведение хоста при нехватке памяти

Анализ статистики раздувания памяти

Вы можете проверить статистику всплывающей памяти в Esxtop, на вкладке Memory Ballooning у виртуальной машины, а также с помощью графиков производительности vCenter.

Вы увидите счетчик «MEMCTL/MB», который показывает общую активность раздувания (22110 МБ). Значения «curr» и «target» являются накопленными значениями «MCTLSZ» и «MCTLTGT», как описано ниже.

Мы должны искать столбцы «MCTL» для просмотра активности всплывающих окон для каждой виртуальной машины:

Вкладка распределения ресурсов

Вы можете проверить статистику «Раздувание памяти» каждой отдельной виртуальной машины на вкладке «Распределение ресурсов виртуальной машины (Resource Allocation Tab)». Это конкретное значение VM Ballooned составляет 5,08 ГБ.

Вкладка Performance Charts в vCenter 5.5

Вы можете сгенерировать пользовательские графики производительности в vCenter, чтобы понять статистику Memory Ballooning в памяти всех виртуальных виртуальных машин на хосте ESXi или отдельных виртуальных машинах.

Источник

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

Данная небольшая заметка посвящена использованию virtio balloon драйвера для «горячего» изменения количества оперативной памяти в гостевых системах. Технология появилась достаточно давно, и использовать её довольно просто, но при этом возникает множество интересных вопросов.

Как это использовать?

Узнать количетво памяти, выделенное для вирт машины можно при помощи команды info balloon в консоли qemu monitor

В гостевой системе (Linux) можно воспользоваться командой free для получения информации об использовании оперативной памяти

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

В гостевой системе

Для Windows систем процесс полностью аналогичен

После урезания памяти

Как это работает?

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

Если необходимо уменьшить количество памяти выделяемое машине, то сначала balloon процесс «раздувается» до необходимого размера, а потом позволяет хосту освободить нужное количество памяти

Увеличение количества памяти происходит аналогичным образом.

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

Поэтому для эффективного использования balloon драйвера необходимо каким-то образом получать информацию об реальном использовании памяти в гостевой системе и на основе полученных данных принимать решение об ограничениях. Подобный механизм разрабатывается в настоящий момент. Адам Литке (Adam Litke) Разработал серию патчей для qemu и balloon драйвера, которые позволяют получать дополнительную информацию об использовании памяти. (Делается это при помощи команды info balloon в qemu мониторе.) Последние версии libvirt уже содержат код, который парсит обновленный вывод команды info balloon для получения информации об оперативной памяти гостевой системы. Но по словам Адама пока что эти патчи содержат некоторые проблемы связанные с взаимодействием с qemu, и в настоящее время идет активная работа по их доработке.

Но уже сейчас есть несколько способов получения информации от гостевой системы. Например, можно передавать данные об использовании памяти по сети (разумеется в этом случае сеть должна быть настроена в виртуальной машине). Такой способ используется в проекте MoM. Далее я опишу немного другой способ связи между хост системой и виртуальной машиной, при помощи которого мы сможем управлять balloon драйвером более эффективно.

Получение информации от гостевой системы.

Для передачи информации из гостевой системы на хост можно воспользоваться virtio-serial механизмом. Подробней про него можно прочитать тут и тут. Для совсем тестового примера работы с памятью воспользуемся каналом (pipe) между гостем и хостом. Связь схематично показана на рисунке ниже.

Для создания подобного virtio интерфейса необходимо создать два fifo файла и прописать необходимые параметры qemu

Теперь qemu monitor доступен через файлы mon.in и mon_out, файлы mem_pipe.in и mem_pipe.out служат для сообщений с гостевой системой через созданный канал. На гостевой системе при этом создается устройство /dev/virtio-ports/mem, служащее для приема и передачи сообщений к хост системе.

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

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

Разумеется в реальных задачах логика управления памятью должна опираться на более подробные данные анализа, включая в себя оценки роста потребления памяти и прогнозы дальнейшего использования, но включение этих возможностей принципиально осуществимо уже с имеющимися механизмами. Надо отметить, что доработка патчей для balloon драйвера позволит получать данные о потреблении памяти не из гостевой системы, а напрямую из qemu monitor.

Источник

Виртуализация. VMware vSphere

Тут собираю интересное по интересующей меня теме виртуализации.

Страницы

Подпишись на обновления по RSS

Посты по email

Обо мне

Михаил Москва, Russia Кроме званий VCP по четырем поколениям продуктов этой компании, удостоен звания VMware vExpert. Являюсь автором книги «Администрирование VMware vSphere».
С февраля 2012 работаю в компании VMware.
Адрес моей электронной почты mikhail.mikheev@vm4.ru.

Все высказанное здесь представлено “как есть” и не предоставляет каких-либо гарантий и прав. Позиция автора может не совпадать с позицией работодателя. Просмотреть профиль

Последние комментарии

Подпишись на комментарии

Архив блога

Постоянные читатели

Ярлыки

понедельник, 2 августа 2010 г.

Memory management

Вот у нас есть сервер ESX(i), для простоты один. У его есть сколько-то оперативной памяти для виртуальных машин (“Доступная память”), и на нем работает сколько-то виртуальных машин. Этим виртуальным машинам выделено сколько-то памяти (“Показанная память” ), и они сколько-то этой памяти потребляют (“Потребляемая память” ). Что можно рассказать про это?

Несколько общих слов

Memory Overcomitment

Вводная к размышлениям

Мы будем рассуждать о потреблении памяти виртуальными машинами, а точнее – гостевыми ОС и приложениями.
Основная идея в чем – “показанная” серверу (тут неважно – физическому или виртуальному) оперативная память никогда не загружена на 100%. Почему? У вас загружена именно так? Значит вы хреново спланировали этот сервер, согласны?

Утверждение 1 – мы должны стремиться к тому. что виртуальные машины не должны все время потреблять 100% от “показанной” им памяти. Таким образом, прочие соображения я буду основывать на том, что у вас именно так. То, что некоторые задачи занимают чем-то всю свободную память – здесь не учитываем, так как разговор идет в общем.

Утверждение 3 – в вашей инфраструктуре сделан запас по оперативной памяти серверов, то есть “доступной” памяти. Этот запас делается из следующих соображений:

Выделение по запросу

То, чего нет у других. Ну или я не знаю что есть. (помните, пост про vDiva – “Вы считаете себя нереально крутым спецом по виртуализации, хотя ни разу в жизни не видели Xen, Hyper-V или KVM”).

Как это работает
Виртуальной машине выделили (“показали”) два гигабайта. Виртуальную машину включили. Что происходит дальше?
Этап 1 – включение. Часто мне приходится слышать о том, что при старте гость забивает нулями всю память – уважаемые читатели, кто в теме просветите меня – так ли это на самом деле, мои изыскания привели к противоречивым выводам. Допустим это так – потому что это самый плохой случай – ведь гость на старте делает вид, что ему нужна вся “показанная” ему память. Ок, гипервизор ему всю выдает. Итак, на этапе 1 “потребляемая” память равна “показанной”, в самом плохом случае.
Этап 2 – гость стартовал все службы, службы начали работать, создавать нагрузку. Но не сто процентов памяти потребляется, см. утверждение 1. Например, 1200 мегабайт из выделенных 2000. То есть гость 800 мегабайт пометил у себя в таблице памяти как “свободная”. По хорошему, гипервизору надо бы ее забрать. Он и забирает, для этого используется механизм balloon(!). Т.е. одна из задач балон-драйвера (подробности о нем см. ниже) – это отбирать ранее выданною, но сейчас ненужную гостю память. Итак, балон раздулся, затем сразу сдулся. Что получилось – гостю 1200 мегабайт нужно, поэтому они балоном или не отнялись, или сразу вернулись обратно. Но больше памяти гостю, обычно, не нужно – и он больше не просит. А раз не просит, гипервизор ему больше и не дает.

Насколько часто это применяется к разным группам виртуальных машин
Работает этот механизм всегда, когда виртуальная машина потребляет не 100% “показанной” памяти. То есть всегда, кроме первых минут после включения и редких пиков, этот механизм работает, и заметно экономит нам память.
Если виртуальная машина не потребляет всю память часто – механизм очень полезен. Для некоторых тестовых – 100% времени. Для производственных серверов – как минимум ночью. А если часть серверов нагружается в другое время суток чем оставшаяся часть – вообще шоколадно. Для инфраструктурных – иногда бОльшую часть времени.

Эффект на производительность
Если и есть негативный, то не должен быть большим.

transparent memory page sharing

Технология с самым сложно звучащим названием.

Как это работает
Гипервизор считает контрольные суммы, хеши, страниц оперативной памяти. Находит одинаковые (для одной или нескольких виртуальных машин) страницы. И одинаковые страницы из разных “виртуальных таблиц памяти” адресует в одну единственную страницу в памяти реальной. Получается, на пустом месте гипервизор делает “потребляемую” память меньше чем она могла бы быть без данного механизма. Ну про “”на пустом месте” я конечно соврал – гипервизор тратит ресурсы процессоров сервера на подсчет контрольных сумм. Но с учетом того, что, как правило, ресурсов процессора у нас дофига, этот обмен нам очень выгоден.
Иллюстрация:

Насколько часто это применяется к разным группам виртуальных машин
Сложный вопрос. Сложность во все более широко используемом механизме Large Pages. Если у вас Windows 7/2008 + Nehalem, и используются страницы памяти по 2 МБ, теория гласит что эффект от page sharing будет маленьким. Хотя в реальности там довольно сложный алгоритм:
ESX(i) разбивает 2 МБ страницу на 4 КБ, считает их хеши, но не использует механизм page sharing пока памяти хватает. А вот если перестало хватать – перед тем как включать какой-то из механизмов подкачки начинает делать sharing этих маленьких 4 КБ кусков.
Что говорит практика по эффективности и безболезненности такого подхода– у меня пока мнения не сложилось.
А если у вас железо или софт постарее, или эти большие страницы принудительно отключены – эффект обычно офигенный.

balloon driver / vmmemctl

Самая радостная для русского уха технология.

Как это работает
Один из компонентов VMware tools – это драйвер устройства vmmemctl. По команде ESX(i) он начинает запрашивать у гостевой ОС память, так же как это делают приложения гостевой ОС. Т.е. этот драйвер раздувает тот самый “баллон” внутри, отнимая память у гостя.
Зачем это надо? Для решения двух задач.
Первая уже описана выше – если гостю были выделены страницы памяти, которые он уже перестал использовать, то гипервизор не может такие свободные страницы отличить и забрать. А раздувшемуся внутри “баллону” гость сам их отдаст в первую очередь, и затем не попросит у гипервизора их обратно. Страницы памяти, занятые “баллоном”, гипервизор отличит, и перестанет их адресовать для виртуальной машины, которой они были адресованы до сего момента. Посмотрите на иллюстрацию ниже – страницы памяти, гостем для себя помеченные как “свободные”, помечены звездочками слева. А справа, в следующем состоянии описываемого механизма, они уже не занимают железную память сервера.
Иллюстрация:

Вторая задача – когда гостю выделено, например, два гигабайта, а один гигабайт из них надо отнять. Характерный пример – когда памяти сервера перестало хватать резко увеличившемуся числу виртуальных машин. А число их резко увеличилось из-за сбоя одного из серверов, и рестарта его ВМ на другом.
Так вот, у ВМ надо отнять память. Гипервизор раздувает баллон, гость начинает свопировать (в свой собственный файл\раздел подкачки. То есть balloon – это способ гипервизору задействовать механизм подкачки гостя). Реальную память, теперь занятую баллоном(с точки зрения гостя), гипервизор отдает другой ВМ. Кстати, в моем примере гипервизор отдаст команду отнять гигабайт. А весь ли гигабайт баллон отнимет? Может быть, и не весь – гость вполне может отказать ему в памяти, если сочтет что другим компонентам память нужнее. Если баллон не справился, то гипервизор доотнимет оставшееся с помощью memory compression и vmkernel swap.

Насколько часто это применяется к разным группам виртуальных машин
Первая задача – отнимание незанятой памяти, стабильно актуальна для виртуальных машин любой группы.
Вторая задача – мне видится мало актуальной. Давайте разберем ее слегка подробнее.
Итак, из чего может взяться ситуация, когда у одной ВМ память надо отнять, чтобы отдать другой? Я вижу несколько вариантов:

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

Далее ситуация разветвляется. Если у вас есть DRS, то он быстренько разнесет виртуалки по разным серверам, и баллону работать не придется.
А вот если DRS нет, или он не в автоматическом режиме – вот тут мы приходим к нехватке на всех физической памяти. И гипервизор отнимет память у части машин с помощью баллона.
У многих из вас нет DRS?
У тех, у кого таки нет DRS – часто у вас ломаются серверы?
Наконец, даже наличие баллона что означает – что запустятся все виртуалки, но всем будет хреново от нехватки памяти (правда, какие-то виртуальные машины могут “остаться на коне”, за счет опускания других ВМ в еще большее свопирование – см. такие настройки как reservation и shares).

Отсюда вывод – наличие баллона это несомненный плюс для решения задачи один, но не панацея для решения задачи два.

Эффект на производительность
Для задачи один незаметный – отнимается только ненужная память.
Для задачи два разный – см. далее.

memory compression

Новинка, этот механизм появился только в 4.1.

Насколько часто это применяется к разным группам виртуальных машин
Редко – как я выше писал, при адекватном планировании и наличии DRS почти никогда.

Эффект на производительность
См. далее.

vmkernel swap

Насколько часто это применяется к разным группам виртуальных машин
См. описание второй задачи для баллона – отнять и поделить. Я думаю, что такая задача встает редко.
Плюс vmkernel swap в том, что он работает всегда. Гипервизору нет дела ни до чего – ни до наличия vmware tools и vmmemctl в госте, ни до чего другого – задействовать vmkernel swap можно всегда.
Минус – тормоза будут значительными.

Эффект на производительность
См. далее.

Источник

Запуск Windows под Linux KVM

Задача: запустить некоторое количество виртуальных машин с Windows на типовом Линукс-сервере.

Решение: любой современный Linux-дистрибутив, «родная» технология виртуализации KVM, Windows 2003 и настройки, описанные ниже.

Выбор гостевой ОС

Windows XP работает под Linux KVM неустойчиво. Основные ошибки — потребление 100% процессора процессом csrss.exe (вплоть до обрыва RDP-сессий) и BSOD с кодом IRQL_NOT_LESS_OR_EQUAL в HAL.DLL. Если удалось достичь стабильной работы, обязательно отключите автоматическую установку обновлений! По нашему опыту, для работы WinXP под KVM они стали главным источником проблем.

Windows 7 работает нормально, но согласно счётчикам Proxmox, требует для работы более 3 гигабайт ОЗУ.

Для ознакомительных целей годится любой опубликованный на RuTracker дистрибутив.

Первый запуск и virtio

Теперь про самое важное на данном этапе, т.е. про диски.

После того, как установка системы и драйверов будет полностью завершена, в команде запуска следует убрать «-boot» и все строки «-drive», кроме первой, т.к. временный диск и ISO-образы станут не нужны (обратите внимание на добавленный » if=virtio «!):

Про пользу virtio, варианты настройки сети и параметры командной строки kvm читайте в habrahabr.ru/post/167099

Ballooning

Традиционный подход — сразу при запуске виртуальной машины (ВМ) выделять ей блок ОЗУ заданного размера, например, 512 мегабайт. Его недостаток — в те моменты, когда в памяти ВМ есть неиспользуемое пространство, в других ВМ и хост-системе её может не хватать.

Memory ballooning — это механизм динамического (а) выделения хост-ОЗУ для ВМ по мере необходимости и (б) возвращения неиспользуемых блоков по мере освобождения. Благодаря ему становится возможным одновременно запускать множество ВМ, суммарный объём виртуального ОЗУ в которых больше объёма физического ОЗУ в хост-системе, при условии, что они не станут использовать максимально разрешённый объём все сразу. Благодаря этому память хост-системы распределяется между ВМ так же гибко, как между обычными процессами.

Создание виртуальных ресурсов, превышающих физические по объёму, обозначается любимыми для многих хостеров терминами «overcommit» и «overselling».

Гостевое устройство для связи с MOM диспетчер оборудования (devmgmt.msc) Windows увидит как «PCI standard RAM controller» неизвестного типа. В отличие от virt-stor и virt-net, драйвер к нему не будет предложено установить автоматически. Вместо этого, следует зайти в свойства устройства, на вкладке «Драйвер» выбрать обновление и вручную указать путь к balloon.inf на VirtIO CD (пруф). После этого устройство переименуется в «VirtIO Balloon Driver».

По умолчанию Windows 2003 разрешает выключать себя единственным способом — ввести логин-пароль, выбрать Пуск => «Завершение работы», ввести примечание, нажать «OK». Разумеется, на VDS-ферме такой подход неприемлем. KVM (и QEMU) умеет эмулировать ACPI. Команда «system_powerdown» аналогична нажатию кнопки питания на физическом компьютере, но Windows её проигнорирует. Лечится следующим REG-файлом:

Кэширование

Если образ гостевого диска хранится на VDS-ферме в виде файла, кэширование гостевых файлов может оказаться двойным — сначала их кэширует гостевая ОС при обращениях к виртуальному диску, затем ОС фермы при обращениях к физическому.

Все без исключения источники в Сети советуют не использовать writethrough как наиболее медленный. По субъективной оценке, для ВМ с Windows оптимален writeback, для ВМ с Linux и FreeBSD — none.

Зависания сети

Единственной серьёзной проблемой, которую однозначно вызывает ошибка в KVM, являются подвисания гостевой сети при интенсивном трафике: bugs.centos.org/view.php?id=5526 (кроме собственно описания ошибки, там же есть важные ссылки на другие багтрекеры).

Рекомендации, предлагаемые участниками обсуждений (обновление qemu-kvm и ядра, изменение параметров командной строки, использование vhost-net), к сожалению, пока не сумели её решить.

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

Автоматизировать данное действие в Windows можно с помощью AutoIt, если создать файл PingFailed_ResetNic.au3 и вызывать его Диспетчером заданий каждые несколько минут:

Подобное «решение» не везде может рассматриваться как удовлетворительное, но в ряде случаев его достаточно, чтобы свести негативный эффект к приемлемому минимуму, позволяющему дождаться выхода исправления вместо более кардинальных мер.

Источник

memory ballooning что это такое