У меня есть базовый вопрос по настройке VM. Я использую Hyper-V, но я думаю, что вопрос довольно общий. Это для домашнего офиса, я хочу получить достаточно хорошую производительность на VM без большого труда. Я использую VM для тестирования/отладки моего программного обеспечения. В идеале я бы запустил все ОС, но только одна (вероятно, ноль большую часть времени) будет активно использоваться в каждый момент времени.
Есть ли какие-то общие рекомендации по распределению памяти для виртуальных машин? С одной стороны, вы можете разделить общую память на количество виртуальных машин (4 ГБ всего, 4 виртуальных машины -> 1 ГБ каждая). С другой стороны, вы можете дать каждой виртуальной машине полную память и позволить ОС вынести решение. Я предполагаю, что оба варианта неверны! Я ищу «правило большого пальца» для разумной производительности. Я понятия не имею, как сервер виртуальных машин управляет памятью для виртуальных машин.
[править] Я задал этот вопрос, потому что ошибочно предположил, что Hyper-V (версия 2008 R2) может динамически предоставлять дополнительную память виртуальным машинам, если она доступна. Я думал, что я могу перераспределить память, пока пик моего использования приходится только на одну виртуальную машину за раз. Поскольку Hyper-V хочет выделять фиксированную память для каждой виртуальной машины при их запуске, мне нужно либо закрыть некоторые виртуальные машины и запустить только те, которые мне нужны, либо настроить виртуальные машины на более низкое выделение памяти и убедиться, что физической памяти достаточно для всех выделений, а также для процесса Hyper-V и (возможно) хостовой ОС.
Похоже, что у VMWare есть больше возможностей в этом направлении, как отмечено в предоставленных ответах. [/edit]
Спасибо, Бретт.
решение1
Как правило, вы хотите знать, что в худшем случае достаточно физической оперативной памяти для надежной работы всех стандартных функций из оперативной памяти. Что это за магическое число, зависит от ОС и от того, для чего вы используете гостевую ОС. Вы можете с радостью загрузить Windows 2003 Server с парой сотен мегабайт оперативной памяти, некоторые компактные дистрибутивы Linux с 30 мегабайтами или меньше и так далее, но если вы хотите запустить SQL Server в гостевой системе с многогигабайтными базами данных, то вам нужно убедиться, что у него действительно есть реальная оперативная память, резервирующая пару гигабайт оперативной памяти, которые, как он думает, у него есть.
То, как гипервизор обрабатывает ОЗУ, сильно различается в зависимости от поставщиков и продуктов. Hyper-V не поддерживает то, что называется перераспределением памяти, поэтому вы ограничены выделением ОЗУ на основе того, что у вас физически доступно. ESX от VMware допускает перераспределение, устанавливая правила арбитража конфликтов (доли), чтобы контролировать то, что происходит, когда виртуальные машины заняты, а общий объем физической ОЗУ недостаточен для покрытия нагрузки. В среде Hyper-V у вас нет такого уровня контроля, поэтому вам нужно заранее выделить достаточный объем ОЗУ.
У VMware есть еще несколько приемов, помогающих справиться с чрезмерным выделением памяти: прозрачное распределение страниц и раздувание памяти.
Прозрачный обмен страницами — это, по сути, хранилище одного экземпляра для ОЗУ — гипервизор отслеживает блоки ОЗУ, выделенные для каждой виртуальной машины, и если он обнаруживает общие блоки в нескольких виртуальных машинах, он сохраняет только одну копию и указывает на нее всем виртуальным машинам — если какая-либо виртуальная машина впоследствии пытается записать данные в этот блок, она отделяет копию, чтобы не произошло ничего плохого. В однородной среде виртуальных машин это может сэкономить изрядное количество ОЗУ, не влияя на производительность.
Memory Ballooning — это механизм, который позволяет гипервизору «заимствовать» оперативную память, выделенную для одной виртуальной машины, и отдавать ее более важной, используя драйвер гостевой ОС в первом случае, который выделяет (большой) кусок памяти в этой гостевой системе. После выделения гипервизор может безопасно перераспределить физическую оперативную память, поддерживающую память, выделенную ему драйвером balloon. Преимущество этого по сравнению с прямым подходом, когда гипервизор просто переносит память гостевой виртуальной машины на диск, чтобы перераспределить оперативную память, заключается в том, что гость, теряющий физическую оперативную память, знает, что память используется чем-то, и значительно снижается риск того, что «заимствованная» оперативная память будет выделена для каких-либо важных системных функций в гостевой системе.
Отредактировано для добавления: Я никогда не пытался увидеть, что происходит с Hyper-V, когда вы пытаетесь запустить виртуальные машины, которые будут требовать больше памяти, чем доступно физической оперативной памяти; во всей документации, которую я смог найти, говорится, что виртуальные машины получают всю оперативную память, которую вы для них настроили, а затем гипервизор и хостовая ОС выделяют то, что осталось. Hyper-V не имеет механизма для применения минимального резерва оперативной памяти к виртуальной машине, а затем выделения остатка из пула, хотя он предоставляет такой механизм для ресурсов ЦП. Опять же, ESX\ESXi от VMware предоставляет такую возможность.
Стоит помнить, что вам также необходимо спланировать физическую память, которая необходима как гипервизору, так и хостовой ОС (не обращайте внимания на последнюю, если вы используете сервер Hyper-V на «голом железе»).Советы по настройке производительности для Hyper-Vутверждает, что в дополнение к XGig оперативной памяти, имеющейся в вашей виртуальной машине, вам необходимо иметь:
- 300 МБ для гипервизора
- плюс 32 МБ для первого ГБ оперативной памяти, выделенной каждой виртуальной машине
- плюс еще 8 МБ за каждый дополнительный ГБ оперативной памяти, выделенной каждой виртуальной машине
- плюс 512 МБ для операционной системы хоста, работающей на корневом разделе
Если у вас недостаточно физической оперативной памяти для этого, то производительность и, возможно, стабильность работы серьезно пострадают.
решение2
Hyper-V в Windows Server 2008 R2делаетподдержка функции динамической памяти (у меня SP1 - не уверен, была ли она в версии RTM). Я понимаю, что ваш вопрос довольно старый, так что, вероятно, ее не было, когда вы его задавали.
Я начал с выделения статической памяти каждой гостевой виртуальной машине, но быстро исчерпал свой сервер. Динамическая память позволяет вам назначать начальный (возможно, низкий) объем и максимальный объем на виртуальную машину. Затем она будет выделять память по требованию, а также восстанавливать неиспользуемую память. Вам нужно отредактировать настройки каждой виртуальной машины, чтобы настроить это — это недоступно при создании новой виртуальной машины. Я только что перенастроил несколько виртуальных машин для использования динамической памяти и сократил общее выделение памяти почти вдвое.
Виртуальные машины, которые я настроил для динамической памяти, показывают текущую потребность в памяти и ее статус. Выделенная виртуальная машина все еще работает в пределах своего первоначального выделения в 1 ГБ. Сервер Exchange (второй сверху) — большая жирная свинья, которая сдула свой первоначальный 1 ГБ и получила еще несколько. Эта функция позволяет настраивать буфер (по умолчанию 20%), поэтому Hyper-V предоставил Exchange требуемый объем плюс немного больше.
решение3
Это не общий вопрос, потому что Hyper-V не может делать разделение страниц памяти, как VMWare, эта технология может значительно изменить способ выделения памяти ВМ. Если Hyper-V поддерживает это, я бы посоветовал вам выделить вашим ВМ начальный объем, а затем посмотреть на фактическое использование с течением времени для каждой ВМ, изменяя выделение по мере того, как вы узнаете больше о ее поведении.