Виртуализация. Оптимизация использования памяти Hyper-V

Посетителей: 5034 | Просмотров: 6453 (сегодня 0) Шрифт:

При размещении виртуальных рабочих нагрузок наиболее важным для общей производительности аппаратным ресурсом является, пожалуй, физическая память. Крайне важно распределять память так, чтобы каждая виртуальная машина (ВМ) располагала необходимой ей памятью, но при этом память не тратилась бы без толку. Ниже приведены несколько ключевых соображений для распределения памяти при работе с Microsoft Hyper-V.

Соображения архитектуры NUMA

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

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

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

Версии Hyper-V для Windows Server 2008 и 2008 R2 не поддерживают соответствие памяти узлам NUMA напрямую. Другими словами, ВМ нельзя напрямую настроить на использование определенного узла NUMA. Сообщается, что эта возможность будет существовать в версии Hyper-V для Windows Server 8. Тем не менее, возможно предпринять действия, сокращающие шансы использования нелокального узла NUMA ВМ.

Фокус в том, чтобы рассчитать размер каждого узла NUMA. Например, предположим, что наш сервер снабжен двумя восьмиядерными процессорами и 128 ГБ ОЗУ. Размер узла NUMA можно рассчитать, разделив объем памяти (128 ГБ) на число ядер ЦП (16). В данном конкретном случае размер узла NUMA будет составлять 8 ГБ.

Hyper-V пока не позволяет нам назначить определенный узел NUMA определенной ВМ. Однако, поскольку известно, что размер узлов NUMA на данном сервере составляет 8 ГБ, можно догадаться, что любая ВМ, которой выделено более 8 ГБ памяти, будет использовать память из нескольких узлов NUMA. Ограничение памяти, выделяемой ВМ, 8 ГБ или менее (в рассматриваемом случае) увеличивает шансы, что ВМ будет использовать память из единственного узла NUMA, тем самым повышая производительность.

Издержки Hyper-V

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

Необходимо зарезервировать минимум 300 МБ для низкоуровневой оболочки и 512 МБ для несущей ОС, работающей в родительском разделе. Однако большинство рекомендаций утверждают, что для родительского раздела следует зарезервировать 2 ГБ.

Несущий раздел следует использовать только для Hyper-V (хотя в нем также можно запускать ПО инфраструктуры и безопасности, такое как агенты управления, агенты резервного копирования и брандмауэры). Следовательно, рекомендованный объем в 2 ГБ предполагает, что родительский раздел не будет использоваться для дополнительных приложений или ролей сервера.

Hyper-V не позволяет выделять напрямую несущему разделу. По сути, он использует то, что останется. Поэтому следует помнить, что 2 ГБ памяти несущего сервера следует оставить невыделенными, чтобы они были доступны родительскому разделу.

Выделение памяти гостевым машинам

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

ВМ с 1 ГБ ОЗУ или менее используют только около 32 МБ памяти на издержки, связанные с виртуализацией. Сюда следует добавлять 8 МБ за каждый дополнительный гигабайт ОЗУ. Например, ВМ с 2 ГБ ОЗУ будет использовать 40 МБ (32+8) памяти на издержки, связанные с виртуализацией. Аналогично, ВМ с 4 ГБ памяти будет терять таким образом 64 МБ.

Динамическая память

В Windows Server 2008 R2 с пакетом обновления 1 была представлена новая функция динамической памяти, позволявшая ВМ потреблять память динамически, в зависимости от текущей нагрузки. Это также позволяет использовать физическую память сервера сверх обычного, для использования большего числа ВМ, чем было бы возможно иначе. Несмотря на все преимущества динамической памяти, при ее использовании важно следовать некоторым правилам, чтобы избежать недостатка памяти у ВМ.

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

Одним из наиболее важных соображений здесь является рабочая нагрузка ВМ. Если приложение на ВМ разработано для использования фиксированного объема памяти, лучше дать ВМ именно тот объем памяти, который нужен этому приложению, вместо использования динамической памяти.

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

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

ОЗУ для запуска

Одной из наиболее важных для понимания концепций в области динамической памяти является ОЗУ для запуска. При использовании динамической памяти каждой ВМ необходимо назначить ее значение ОЗУ для запуска. Это значение отражает объем физической памяти, который ВМ будет первоначально использовать после загрузки. Что более важно, ОЗУ для запуска также представляет минимальный объем физической памяти, потребляемый ВМ. Использование памяти ВМ не может быть ниже значения ОЗУ для запуска.

Учитывая это, корпорация Майкрософт рекомендует избегать назначения ВМ больших объемов ОЗУ для запуска. ОЗУ для запуска лучше всего основать на ОС, используемой ВМ. Корпорация Майкрософт рекомендует использовать 512 МБ ОЗУ для запуска ВМ, использующих Windows 7, Windows Vista, Windows Server 2008 и Windows Server 2008 R2. Если ВМ будут использовать Windows Server 2003 или Windows Server 2003 R2, корпорация Майкрософт рекомендует 128 МБ ОЗУ для запуска.

Для использования ВМ динамической памяти последняя должна поддерживаться ОС, работающей на этой ВМ. Windows XP не поддерживает динамическую память. При попытке запустить Windows XP на ВМ, настроенной для использования динамической памяти, ОС может получить доступ только к ОЗУ для запуска.

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

Также может понадобиться скорректировать значение максимального объема ОЗУ. Это значение указывает верхний предел физической памяти, который может использовать ВМ. По умолчанию Hyper-V устанавливает максимальный объем ОЗУ каждой ВМ на 64 ГБ. Если некоторые ВМ не требуют столько физической памяти, может потребоваться снизить значение максимального объема ОЗУ.

Вес памяти

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

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

Почти на всех несущих серверах имеются ВМ, которые важнее других. Hyper-V позволяет определять приоритетность ВМ, так что в случае недостатка физической памяти память будет выделяться ВМ с более высоким приоритетом в первую очередь. Определить приоритет потребности ВМ в динамической памяти можно, корректируя ее вес памяти. ВМ с более высоким весом памяти имеют приоритет перед ВМ в меньшими весами памяти.

Другой параметр, который необходимо настроить для каждой ВМ, использующей динамическую память, – буфер памяти. Параметр буфера памяти контролирует, сколько памяти каждой ВМ следует попытаться зарезервировать в качестве буфера. Это значение выражается как процент. Например, если ВМ использует 4 ГБ выделенной памяти, а буфер памяти установлен на 50 процентов, ВМ может поглотить до 6 ГБ памяти.

Буфер памяти не гарантирует, что память в буфере будет доступна для ВМ. Он просто контролирует, сколько памяти ВМ следует попытаться запросить. Следует отметить, что поскольку буфер памяти выражается как процент, объем памяти в буфере меняется в соответствии с объемом памяти, используемой ВМ в конкретный момент времени. Все ВМ, использующие динамическую память, запускаются используя минимальный объем памяти. Они динамически корректируют использование памяти в зависимости от требований, предъявляемых к их памяти рабочими нагрузками.

Конфигурация памяти

Собственно процесс настройки использования памяти ВМ прост. Откройте диспетчер Hyper-V и щелкните правой кнопкой мыши ВМ (поскольку память каждой ВМ управляется независимо). Выберите команду «Параметры» из контекстного меню. При появлении диалогового окна «Параметры» щелкните «Память».

Hyper-V предоставляет возможность либо выделить ВМ статический объем памяти, либо использовать динамическую память (см. рис. 1). При выборе динамической памяти параметры ОЗУ для запуска, максимального объема ОЗУ, буфера памяти и веса памяти можно настроить прямо в диалоговом окне «Параметры».

Рис. 1. Выделение памяти для виртуальной машины можно скорректировать через диалоговое окно «Параметры».

Если ресурсы физической памяти несущего сервера ограничены, обычно необходим компромисс между использованием статической и динамической памяти. Статическая память обычно обеспечивает лучшую производительность в целом (при адекватном выделении памяти). Динамическая память может вызвать сложности, но она обычно допускает большую плотность ВМ.

Узлы numa windows 10

Сообщение ramshik » 19 янв 2017 05:44

Доброго дня все никак не могу вкурить что к чему в NUMA

Итак есть сервак HP GEN8 DL160 два ксеона каждый по 8 ядер 16 потоков итого имеем 32 потока(виртуальных процессора) и 224 гига оперативной памяти.

Установлена роль гипервизора с охватом NUMA

2ве виртульные машины

1 терминал Citrix xenapp 6.5
Выделенные ресурсы
12 Процессоров
45 гигов памяти

В настройках показывает
Узлов NUMA -1
Cокетов-1

(Если машине выделяю больше оперативы то в параметрах показывает как и на SQL Узлов NUMA -2
Cокетов-2)

2 SQL 2014
Выделенные ресурсы
12 Процессоров
135 гигов памяти

В настройках показывает
Узлов NUMA -2
Cокетов-2

Суть вопроса такова
Чему ровен 1 NUMA узел -сколько процессоров это или сокетов.

Может кто на примере разложить что к чему и сколько нужно указывать максимальное чило NUMA на сокет

Re: Помощь с NUMA

Сообщение leu21 » 08 фев 2017 11:42

Архитектура NUMA делит память и процессоры на группы, которые называются узлами NUMA. Для каждого отдельного процессора в системе память, расположенная в том же узле NUMA, что и сам процессор, является локальной, а память в другом узле NUMA — удаленной. Доступ к локальной памяти осуществляется быстрее.

Большинство современных операционных систем и высокопроизводительных приложений, рассчитанных на использование сразу нескольких процессоров и большого объема памяти, например Microsoft SQL Server, включают оптимизации, которые распознают топологию NUMA компьютера и адаптируются к ней. Чтобы избежать потерь при удаленном доступе, приложения с поддержкой NUMA выделяют хранилище для данных и направляют потоки процессоров на доступ к данным в том же узле NUMA Подобная оптимизация позволяет сократить время доступа к памяти и уменьшить трафик обращений к памяти.

При запуске виртуальной машины Hyper-V пытается выделить всю необходимую для нее память в одном физическом узле NUMA (если объем доступной памяти это позволяет). Если на одном узле памяти недостаточно, Hyper-V выделяет память еще на одном узле NUMA. Это называется охватом NUMA. Дополнительные сведения об охвате NUMA см. в разделе Параметры сервера: охват NUMA, который приводится ниже.

Как использовать все узлы NUMA с openMP в Windows 10

У меня есть доступ к системе с двумя сокетами, состоящей из двух узлов NUMA, для некоторой обработки данных.

Мой код относительно прост, и я использую openMP для основного параллелизуемого цикла, который выглядит следующим образом (k — это параметр функции, а буфер — это массив из нескольких гигабайт длиной n):

Под Linux Mint я могу без проблем скомпилировать gcc, и все ядра на обоих сокетах будут хорошо использованы. Однако в Windows (mingw-gcc на cygwin) используется только один узел NUMA. Так как мой код не очень чувствителен к задержке памяти, я получаю 2-кратное замедление в Windows.

Я не могу понять, как заставить Windows распределять потоки по обоим узлам. Насколько я понимаю, openMP не поддерживает сходство в Windows (в любом случае реализация cygwin mingw-gcc), но я не знаю, как мне это сделать вручную.

Любая помощь очень ценится!

1 ответ

Я нашел причину проблемы. На машине установлено более 64 логических ядер, поэтому для их работы Windows требуется две группы процессоров. По умолчанию каждый узел NUMA помещается в свою собственную группу.

Это исправление: либо отключение HTT, если у вас менее 64 физических ядер, либо отключение группировки NUMA в BIOS. В последнем случае первые 64 логических ядра будут сгруппированы и будут отображаться как один узел NUMA в Windows, а оставшаяся часть помещается во второй узел. Идеальное решение будет зависеть от вашего конкретного приложения, выиграете ли вы от использования всех ядер, или от hyperthreadng.

[РЕДАКТИРОВАТЬ] Вы также можете управлять потоками вручную. Если вы хотите сделать это, я предлагаю покопаться в Processtopologyapi.h а также processthreadsapi.h в частности в функции GetActiveProcessorCount а также SetThreadGroupAffinity ,