Производительность процессора Hyper-V | Microsoft Learn
Twitter LinkedIn Facebook Адрес электронной почты
- Статья
Службы интеграции виртуальных машин
Виртуальная машина Integration Services включает драйверы поддержкой для устройств ввода-вывода, специфичных для Hyper-V, что значительно сокращает нагрузку на ЦП для операций ввода-вывода по сравнению с эмуляциями устройств.
Следует установить последнюю версию виртуальной машины Integration Services на каждой поддерживаемой виртуальной машине. Службы уменьшают загрузку ЦП гостевых компьютеров, от бездействующих гостей до интенсивно используемых гостей и улучшают пропускную способность ввода-вывода. Это первый шаг в настройке производительности на сервере с Hyper-V. Список поддерживаемых гостевых операционных систем см. в статье Обзор Hyper-V.
Виртуальные процессоры
Hyper-V в Windows Server 2016 поддерживает не более 240 виртуальных процессоров на каждую виртуальную машину. Виртуальные машины, для которых используются нагрузки, не требующие интенсивного использования ЦП, должны быть настроены на использование одного виртуального процессора. Это обусловлено дополнительными издержками, связанными с несколькими виртуальными процессорами, например дополнительными затратами на синхронизацию в гостевой операционной системе.
Увеличьте число виртуальных процессоров, если для виртуальной машины требуется более одного ЦП при пиковой нагрузке.
Фоновое действие
Установите последнюю версию Integration Services виртуальной машины.
удалите эмулированного сетевого адаптера с помощью диалогового окна «параметры виртуальной машины» (используйте адаптер Microsoft Hyper-V).
Удалите неиспользуемые устройства, такие как компакт-диски и COM-порты, или отключите их носители.
при отсутствии использования и отключении заставки используйте Windows гостевой операционной системы на экране входа.
Проверьте запланированные задачи и службы, которые включены по умолчанию.
Проверьте поставщики трассировки событий Windows, которые включены по умолчанию, запустив logman.
exe Query-ETS .Улучшение серверных приложений для сокращения периодических действий (например, таймеров).
Закройте диспетчер сервера в основной и гостевой операционных системах.
Не выполняйте запуск диспетчера Hyper-V, так как он постоянно обновляет эскиз виртуальной машины.
exe Query-ETS .ниже приведены дополнительные рекомендации по настройке версии клиента Windows на виртуальной машине для снижения общей загрузки цп.
отключите фоновые службы, такие как «упреждающая выборка» и «поиск Windows».
Отключите запланированные задачи, такие как запланированная дефрагментация.
Виртуальная топология NUMA
чтобы обеспечить виртуализацию больших рабочих нагрузок, Hyper-V в Windows Server 2016 развернутые ограничения масштабирования виртуальных машин. Одной виртуальной машине можно назначить до 240 виртуальных процессоров и 12 ТБ памяти. При создании таких крупных виртуальных машин, скорее всего, будет использоваться память из нескольких узлов NUMA в основной системе.
В такой конфигурации виртуальной машины, если виртуальные процессоры и память не распределяются из одного узла NUMA, рабочие нагрузки могут иметь неплохое снижение производительности из-за невозможности воспользоваться преимуществами оптимизации NUMA.
в Windows Server 2016 Hyper-V представляет виртуальным машинам топологию NUMA. Виртуальная топология NUMA по умолчанию оптимизируется в соответствии с топологией NUMA основного компьютера. Предоставление топологии NUMA виртуальной машине позволяет гостевой операционной системе и установленным в ней приложениям с поддержкой NUMA использовать связанные с NUMA преимущества оптимизаций производительности точно так же, как если бы они работали на физическом компьютере.
Между виртуальной и физической архитектурой NUMA нет различий от перспективы рабочей нагрузки. Когда рабочая нагрузка на виртуальной машине выделяет локальную память для данных и обращается к этим данным на одном и том же узле NUMA, в соответствующей физической системе осуществляется быстрый доступ к локальной памяти.
При этом потерь производительности в процессе доступа к удаленной памяти удается избежать. Только приложения, поддерживающие NUMA, могут использовать преимущества Внума.
Microsoft SQL Server является примером приложения, поддерживающего NUMA. Дополнительные сведения см. в разделе Общие сведения о доступе к неоднородной памяти.
Виртуальную архитектуру NUMA и функцию динамической памяти нельзя использовать одновременно. Виртуальная машина, для которой включена динамическая память, имеет только один виртуальный узел NUMA и ей не предоставляется топология NUMA вне зависимости от параметров виртуальной архитектуры NUMA.
Дополнительные сведения о виртуальной архитектуре NUMA см. в статье Общие сведения о виртуальной архитектуре NUMA Hyper-V.
Дополнительные ссылки
Терминология Hyper-V
Архитектура Hyper-V
Конфигурация сервера Hyper-V
Производительность памяти Hyper-V
Производительность ввода-вывода хранилища Hyper-V
Производительность ввода-вывода сети Hyper-V
Обнаружение узких мест в виртуализированной среде
Виртуальные машины Linux
Требования к системе для Hyper-V в Windows 10
Twitter LinkedIn Facebook Адрес электронной почты
- Статья
Технология Hyper-V доступна в 64-разрядных версиях Windows 10 Pro, Корпоративная и для образовательных учреждений.
Для Hyper-V требуется функция преобразования адресов второго уровня (SLAT). Она есть в текущем поколении 64-разрядных процессоров Intel и AMD.
На узле, имеющем 4 ГБ оперативной памяти, можно запустить три-четыре базовые виртуальные машины, однако для большего числа виртуальных машин потребуется больше ресурсов. Кроме того, можно создать мощные виртуальные машины с 32 процессорами и 512 ГБ ОЗУ в зависимости от оборудования.
Требования к операционной системе
- Windows 10 Корпоративная
- Windows 10 Pro
- Windows 10 для образовательных учреждений
Роль Hyper-V невозможно установить в следующих версиях:
- Windows 10 Домашняя
- Windows 10 Mobile
- Windows 10 Mobile Корпоративная
ОС Windows 10 Домашняя можно обновить до версии Windows 10 Pro. Для этого перейдите в раздел Параметры>Обновление и безопасность>Активация.
Здесь вы можете посетить Магазин Windows и приобрести обновление.Требования к оборудованию
Хотя в этом документе не приводится полный список оборудования, совместимого с Hyper-V, укажем следующие обязательные требования:
- 64-разрядный процессор с поддержкой преобразования адресов второго уровня (SLAT).
- Поддержка расширения режима мониторинга виртуальной машины (технология VT-x на компьютерах с процессорами Intel).
- Не менее 4 ГБ оперативной памяти. Так как виртуальные машины и узел Hyper-V используют память совместно, необходимо обеспечить достаточный объем памяти для обработки предполагаемой рабочей нагрузки на виртуальной машине.
В BIOS системы необходимо включить следующие компоненты.
- Virtualization Technology (Технология виртуализации) — может иметь другое название в зависимости от производителя системной платы.
- Предотвращение исполнения данных на основе оборудования.
Проверка совместимости оборудования
После проверки требований к операционной системе и оборудованию, описанных выше, проверьте совместимость оборудования в Windows, открыв сеанс PowerShell или окно командной строки (cmd.
exe). Для этого введите systeminfo, а затем просмотрите раздел требований к Hyper-V. Если все указанные требования Hyper-V имеют значение Yes, ваша система поддерживает роль Hyper-V. Если хотя бы один элемент имеет значение No, проверьте указанные выше требования и внесите необходимые изменения.
Окончательная проверка
Если все требования к ОС, оборудованию и совместимости соблюдены, сведения о Hyper-V отобразятся на панели управления в окне «Включение или отключение компонентов Windows». Будет доступно два варианта.
- Платформа Hyper-V.
Примечание
Если вы видите элемент Платформа гипервизора Windows, а не Hyper-V в окне Включение или отключение компонентов Windows на панели управления, возможно, ваша система несовместима с Hyper-V. В таком случае перепроверьте указанные выше требования.
Если команда systeminfo запускается на существующем узле Hyper-V, в разделе Hyper-V Requirements отображается следующее сообщение:
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
Объяснение виртуальных ЦП Hyper-V
Указывал ли ваш поставщик программного обеспечения, что вы можете виртуализировать его приложение, но только если вы выделите для него одно или несколько ядер ЦП? Непонятно, что происходит, когда вы назначаете ЦП виртуальной машине? Вы далеко не одиноки.
Примечание. Эта статья была первоначально опубликована в феврале 2014 года. Она была полностью обновлена и актуальна по состоянию на ноябрь 2019 года.0005 не существует . Гипервизор использует реальные ЦП физического хоста для создания виртуальных конструкций, которые представляются виртуальным машинам. Гипервизор контролирует доступ к реальным процессорам точно так же, как он контролирует доступ ко всему остальному оборудованию.
Hyper-V никогда не назначает физические процессоры конкретным виртуальным машинам
Прежде чем двигаться дальше, убедитесь, что вы поняли этот раздел. Назначение 2 виртуальных ЦП системе не означает, что Hyper-V извлекает два ядра из физического пула и навсегда объединяет их с вашей виртуальной машиной. Вы вообще не можете назначить физическое ядро виртуальной машине. Значит ли это, что вы просто не можете удовлетворить запрос поставщика на выделение ядра или двух? Ну, не совсем так. Подробнее об этом ближе к концу.
Общие сведения о планировании процессора операционной системы
Давайте начнем с рассмотрения того, как процессоры используются в обычной Windows. Вот снимок экрана моего диспетчера задач:
Диспетчер задач
Ничего особенного, верно? Выглядит знакомо, не так ли?
Теперь, когда компьютеры никогда или почти никогда не поставлялись в виде многоядерных блоков с несколькими процессорами, мы все знали, что компьютеры не могут работать в многозадачном режиме.
У них был один ЦП и одно ядро, поэтому был только один возможный активный поток выполнения. Но если не считать причудливых графических обновлений, Диспетчер задач тогда выглядел почти так же, как сейчас. У вас был длинный список запущенных процессов, каждый из которых имел метрику, показывающую, какой процент процессорного времени он использует.
Затем, как и сейчас, каждый элемент строки, который вы видите, представляет процесс (или, что впервые в последних версиях диспетчера задач, группу процессов). Процесс состоит из одного или нескольких потоков . Поток — это не что иное, как последовательность инструкций ЦП (ключевое слово: последовательность).
Происходит следующее (в Windows это началось в 95 и NT) операционная система останавливает запущенный поток, сохраняет его состояние и затем запускает другой поток. Через некоторое время он повторяет эти операции для следующего потока. Мы называем это pre-emptive , что означает, что операционная система решает, когда приостановить текущий поток и переключиться на другой.
Вы можете установить приоритеты, влияющие на скорость процесса, но ОС отвечает за планирование потоков.
Сегодня почти все компьютеры имеют несколько ядер, поэтому Windows действительно может работать в многозадачном режиме.
Применение этих концепций к гипервизору
Из-за своей роли диспетчера потоков Windows можно назвать «супервизором» (очень старая терминология, которую вы больше никогда не встретите): система, которая управляет процессами, состоящими из потоков . Hyper-V — это гипервизор: система, которая управляет супервизорами, управляющими процессами, состоящими из потоков.
Диспетчер задач не работает так же для Hyper-V, но происходит то же самое. Существует список разделов, а внутри этих разделов находятся процессы и потоки. Планировщик потоков работает примерно так же, примерно так:
Планирование потоков гипервизора
Конечно, в реальной системе всегда будет выполняться более девяти потоков. Планировщик потоков поместит их все в очередь.
Как насчет соответствия процессоров?
Вы, наверное, знаете, что в Windows можно сопоставить потоки, чтобы они всегда выполнялись на определенном ядре или наборе ядер. Вы не можете сделать это в Hyper-V. В любом случае это будет иметь сомнительную ценность; выделение потока ядру — это не то же самое, что выделение ядра потоку, что многие люди действительно хотят попробовать сделать. Вы не можете запретить ядру запускать другие потоки в мире Windows или в мире Hyper-V.
Как работает планирование потоков?
Самый простой ответ заключается в том, что Hyper-V принимает решение на уровне гипервизора. Это действительно не позволяет гостям вносить свой вклад. Гостевые операционные системы планируют потоки процессов, которыми они владеют. Когда они выбирают поток для запуска, они отправляют его на виртуальный ЦП. Hyper-V берет это оттуда.
Изображение, которое я представил выше, обязательно является чрезмерным упрощением, так как это не просто «первым пришел — первым вышел».
Например, NUMA играет роль. По-настоящему понять эту тему требует довольно глубокого погружения в некоторые сложные идеи. Немногим администраторам требуется такой уровень глубины, и изучение его здесь завело бы эту статью далеко в сторону.
Первое, что имеет значение: если оставить в стороне сходство, вы никогда не знаете, где будет выполняться тот или иной поток. Поток, который был приостановлен, чтобы уступить процессорное время другому потоку, вполне может быть назначен другому ядру, когда он возобновится. Вы когда-нибудь задумывались, почему приложение потребляет ровно 50 % ресурсов двухъядерной системы, а каждое ядро выглядит так, будто оно работает на 50 %? Такое поведение указывает на однопоточное приложение. Каждый раз, когда планировщик выполняет его, он потребляет 100% ядра, на которое попадает. В следующий раз, когда он запускается, он остается на том же ядре или переходит на другое ядро. Какому бы ядру его ни назначил планировщик, оно потребляет 100%. Когда диспетчер задач объединяет свою производительность для отображения, это равно 50% использования — приложение использует 100% из 50% емкости системы.
Поскольку ядро, на котором не запущено приложение, остается в основном бездействующим, в то время как другое ядро работает на пределе, они в совокупности составляют 50% использования за измеренный период времени. Благодаря возможностям более новых версий диспетчера задач теперь вы можете дать ему указание отображать отдельные ядра по отдельности, что делает это поведение гораздо более очевидным.
Теперь мы можем перейти к просмотру количества виртуальных ЦП, назначенных системе, и приоритета.
Что на самом деле означает количество виртуальных ЦП, назначенных виртуальной машине?
Прежде всего следует заметить, что вы не можете назначить виртуальной машине больше виртуальных ЦП, чем имеется логических процессоров на вашем хосте.
Invalid CPU Count
Таким образом, количество vCPU виртуальной машины означает следующее: максимальное количество потоков, которые VM может запустить в любой момент. Я не могу настроить виртуальную машину на скриншоте так, чтобы она имела более двух виртуальных ЦП, потому что на хосте есть только два логических процессора.
Следовательно, третий поток не может быть запланирован. Но если бы у меня была 24-ядерная система и я оставил бы эту виртуальную машину с 2 виртуальными ЦП, то она отправила бы максимум два потока в Hyper-V для планирования. Планировщик потоков виртуальной машины (супервизор) будет держать другие потоки в очереди, ожидая своей очереди.
Но нельзя ли назначить всем виртуальным машинам больше виртуальных ЦП, чем физических ядер?
Да, общее количество виртуальных ЦП на всех виртуальных машинах может превышать количество физических ядер в узле. Это ничем не отличается от того факта, что прямо сейчас на моем двухъядерном ноутбуке «запущено» более 40 процессов. Я могу запускать только два потока одновременно, но я всегда планирую гораздо больше, чем два потока. Windows делает это уже очень давно, и Windows настолько хороша в этом (обычно), что большинство людей никогда не видят необходимости обдумывать то, что происходит. Ваши виртуальные машины (супервизоры) будут создавать потоки для запуска, а Hyper-V (гипервизор) будет планировать их так (в основном), как Windows планировала их с тех пор, как она переросла совместное планирование в Windows 3.
x.
Каково правильное соотношение vCPU к pCPU/ядрам?
Этот вопрос волнует всех. Скажу прямо: в общем смысле на этот вопрос нет ответа.
Конечно, когда-то люди говорили 1:1. Некоторые до сих пор так говорят. И ты знаешь, ты можешь это сделать. Это расточительно, но вы можете это сделать. Я мог бы запустить свою текущую конфигурацию рабочего стола на четырехъядерном 16-ядерном сервере, и у меня никогда не было бы конфликтов. Но я, вероятно, не увидел бы большой разницы в производительности. Почему? Потому что почти все мои темы почти все время простаивают. Если чему-то требуется 0% процессорного времени, что дает ему собственное ядро? Ничего, вот что.
Позже ответ был повышен до 8 виртуальных ЦП на 1 физическое ядро. Хорошо, конечно, хорошо.
Потом стало 12.
А потом рекомендации ушли.
Они ушли, потому что никто не имеет ни малейшего представления. Планировщик будет равномерно распределять потоки по доступным ядрам. Таким образом, количество необходимых физических ЦП не зависит от количества виртуальных ЦП.
Это полностью зависит от того, что нужно рабочим потокам. И даже если у вас есть куча тяжелых потоков, это не означает, что их системы умрут, так как они будут вытеснены другими тяжелыми потоками. Необходимое соотношение vCPU/pCPU полностью зависит от профиля загрузки ЦП и вашего допуска к задержке. Множественные тяжелые нагрузки требуют низкого соотношения. Несколько тяжелых нагрузок хорошо работают со средним соотношением. Легкие нагрузки могут работать в системе с высоким коэффициентом.
Открою вам небольшой грязный секрет о ЦП: каждый раз, когда запускается поток, независимо от того, что это такое, он загружает ЦП на 100% (регулирование мощности изменяет тактовую частоту, а не насыщение рабочей нагрузки). ). CPU — это бинарное устройство; он либо обрабатывается, либо нет. Когда ваши инструменты измерения производительности показывают вам 100 %, 20 %, 50 % или любое другое число, они рассчитывают его на основе измерения времени. Если вы видите 100%, это означает, что ЦП работал в течение всего измеряемого промежутка времени.
20% означает, что процесс выполнялся 1/5 времени и 4/5 времени бездействия. Это означает, что один поток не потребляет 100% ресурсов ЦП, потому что Windows/Hyper-V вытеснит его, когда захочет запустить другой поток. Вы можете иметь несколько «100%» потоков ЦП, работающих в одной и той же системе. Тем не менее, система может реагировать только тогда, когда у нее есть некоторое время простоя, а это означает, что большинство потоков просто пропускают свой отрезок времени. Это позволяет другим потокам быстрее получать доступ к ядрам. Когда у вас есть несколько потоков, всегда стоящих в очереди на активное процессорное время, общая система становится менее отзывчивой, потому что потоки должны ждать. Использование дополнительных ядер решит эту проблему, поскольку распределяет рабочую нагрузку.
Итог: если вы хотите знать, сколько физических ядер вам нужно, вам нужно знать профиль производительности вашей фактической рабочей нагрузки. Если вы не знаете, начните с более ранних рекомендаций 8:1 или 12:1.
[thrive_leads id=’17165′]
Что насчет резерва и взвешивания (приоритет)?
Я не рекомендую вам возиться с настройками ЦП, если вам не нужно решать проблему конкуренции за ЦП. Пусть планировщик потоков сделает свою работу. Точно так же, как установка приоритетов ЦП для потоков в Windows может вызвать больше проблем, чем решить, возня с настройками виртуального ЦП гипервизора может все усугубить.
Давайте посмотрим на экран конфигурации:
Настройки vCPU
Первая группа полей — это резерв. Первое поле представляет собой процент от разрешенного количества виртуальных ЦП, которые необходимо выделить. Его фактическое значение зависит от количества виртуальных ЦП, назначенных виртуальной машине. Второе поле, затененное, показывает общий процент ресурсов хоста, который Hyper-V выделит для этой виртуальной машины. В этом случае у меня есть система с 2 виртуальными ЦП на двухъядерном хосте, поэтому два блока будут одинаковыми. Если я установлю 10-процентный резерв, это будет 10 процентов от общего объема физических ресурсов.
Если я уменьшу выделение до 1 виртуального ЦП, то 10-процентный резерв станет 5-процентным физическим. Второе поле будет автоматически рассчитано при настройке первого поля.
Резерв — это жесткий минимум… вроде того. Если сумма всех резервных настроек всех виртуальных машин на данном хосте превышает 100%, то хотя бы одна виртуальная машина не запустится. Но если резерв ВМ равен 0%, то он вообще не засчитывается в 100% (кажется довольно очевидным, но кто знает). Но если виртуальная машина с 20% резервом простаивает, то другим процессам разрешается использовать до 100% доступной мощности процессора… до тех пор, пока не запустится виртуальная машина с резервом. Затем , как только мощность ЦП будет доступна , зарезервированная виртуальная машина сможет доминировать до 20% общей вычислительной мощности. Поскольку временные отрезки такие короткие, фактически у него всегда есть 20% доступных, но ему приходится ждать, как и всем остальным.
Итак, этот поставщик хочет выделенный процессор? Если вы действительно хотите выполнить их желание, вот как вы это делаете.
Вы вводите любое число в верхнем поле, чтобы второе поле отображало эквивалентную мощность процессора для любого количества процессоров/ядер, которое, по мнению поставщика, им необходимо. Если им нужен один ЦП, а у вас четырехъядерный хост, сделайте так, чтобы второе поле отображало 25%. Вы действительно должны? Ну, я не знаю. Их программное обеспечение, вероятно, не нуждается в такой мощности, но если они могут отключить вас от поддержки за то, что вы их не слушаете, что ж… не вмешивайте меня в это. Настоящая причина, по которой плотность виртуализации никогда не достигает того уровня, на который, по словам производителей гипервизоров, они способны, заключается в произвольных правилах поставщиков программного обеспечения, но об этом мы поговорим в другой раз.
Следующие два поля являются пределом. Теперь, когда вы понимаете резерв, вы можете понять предел. Это предел ресурсов. Это держит руки жадных виртуальных машин подальше от банки с печеньем. Два ящика работают вместе так же, как резервные ящики.
Последний ящик является приоритетным весом. Как указано, это относительно. Каждая виртуальная машина, установленная на 100 (по умолчанию), имеет одинаковую нагрузку с планировщиком, но все они ниже всех виртуальных машин, у которых есть 200, и выше всех виртуальных машин, у которых есть 50, и так далее, и так далее. Если вы собираетесь возиться, вес безопаснее, чем возиться с резервами, потому что вы никогда не сможете предотвратить запуск виртуальной машины, изменив относительные веса. Вес означает, что когда группа ВМ представляет потоки планировщику потоков гипервизора одновременно, ВМ с более высоким весом идут первыми.
А как насчет Hyper-Threading?
Hyper-Threading позволяет одному ядру работать с двумя потоками одновременно — вроде того. Ядро может одновременно активно запускать только один из потоков, но если этот поток останавливается в ожидании внешнего ресурса, тогда ядро управляет другим потоком. Вы можете прочитать более подробное объяснение ниже в разделе комментариев от автора Джордана.
AMD недавно добавила аналогичную технологию.
Чтобы развеять одно серьезное заблуждение: Hyper-Threading не удваивает производительность ядра. Синтетические тесты показывают максимальную отметку в 25% улучшения. Более реалистичные измерения показывают повышение ближе к 10%. 8-ядерная система с технологией Hyper-Threading работает хуже, чем 16-ядерная система без технологии Hyper-Threading. Он может работать почти так же хорошо, как 9-ядерная система.
В так называемом «классическом» планировщике Hyper-V размещает потоки на следующем доступном ядре, как описано выше. Благодаря планировщику ядра, представленному в Hyper-V 2016, Hyper-V теперь предотвращает параллельное выполнение потоков, принадлежащих разным виртуальным машинам, на одном ядре. Однако он будет продолжать вытеснять потоки одной виртуальной машины в пользу потоков другой. У нас есть статья, посвященная основному планировщику.
Осмысление всего
Я знаю, что это много информации. Большинство людей приходят сюда, чтобы узнать, сколько виртуальных ЦП нужно назначить виртуальной машине или сколько всего виртуальных ЦП будет работать в одной системе.
Лично я назначаю 2 виртуальных ЦП каждой виртуальной машине для запуска. Это дает ему по крайней мере два места для запуска потоков, что дает ему отзывчивость. В двухпроцессорной системе это также гарантирует, что виртуальная машина автоматически присутствует на обоих узлах NUMA. Я не назначаю ВМ дополнительные виртуальные ЦП, пока не узнаю, что они ей нужны (или этого требует поставщик приложений).
Что касается отношения vCPU к pCPU, то оно работает примерно так же. Нет никакой формулы или волшебного знания, которое можно было бы просто применить. Если вы планируете виртуализировать существующие рабочие нагрузки, измерьте их текущую загрузку ЦП и подсчитайте ее; это скажет вам то, что вам нужно знать. Вам может помочь набор Microsoft Assessment and Planning Toolkit. В противном случае вы просто добавляете ресурсы и контролируете их использование. Если ваше оборудование не может справиться с вашей рабочей нагрузкой, вам необходимо выполнить горизонтальное масштабирование.
Было ли это полезно?
Да
Отправить отзыв об этой статье
Производительность процессора Hyper-V | Microsoft Узнайте
Редактировать
Твиттер LinkedIn Фейсбук Электронная почта
- Статья
Службы интеграции с виртуальными машинами
Службы интеграции с виртуальными машинами включают усовершенствованные драйверы для устройств ввода-вывода, специфичных для Hyper-V, что значительно снижает нагрузку на ЦП для операций ввода-вывода по сравнению с эмулируемыми устройствами. Вы должны установить последнюю версию служб интеграции виртуальных машин на каждую поддерживаемую виртуальную машину.
Службы снижают загрузку ЦП гостевыми системами, начиная с бездействующих и заканчивая активно используемыми, и повышают пропускную способность ввода-вывода. Это первый шаг в настройке производительности сервера с Hyper-V. Список поддерживаемых гостевых операционных систем см. в разделе Обзор Hyper-V.
Виртуальные процессоры
Hyper-V в Windows Server 2016 поддерживает до 240 виртуальных процессоров на виртуальную машину. Виртуальные машины с нагрузками, не требующими интенсивного использования ЦП, должны быть настроены на использование одного виртуального процессора. Это связано с дополнительными накладными расходами, связанными с несколькими виртуальными процессорами, такими как дополнительные затраты на синхронизацию в гостевой операционной системе.
Увеличьте количество виртуальных процессоров, если виртуальной машине требуется более одного процессора для обработки при пиковой нагрузке.
Фоновая активность
Сведение к минимуму фоновой активности в бездействующих виртуальных машинах высвобождает циклы ЦП, которые могут использоваться другими виртуальными машинами в другом месте.
Установите последнюю версию служб интеграции виртуальных машин.
Удалите эмулируемый сетевой адаптер через диалоговое окно настроек виртуальной машины (используйте специальный адаптер Microsoft Hyper-V).
Удалите неиспользуемые устройства, такие как CD-ROM и COM-порт, или отсоедините их носители.
Держите гостевую операционную систему Windows на экране входа, когда она не используется, и отключайте заставку.
Просмотрите запланированные задачи и службы, которые включены по умолчанию.
Просмотрите поставщиков трассировки ETW, которые включены по умолчанию, запустив
Улучшите серверные приложения, чтобы уменьшить периодическую активность (например, таймеры).
Закройте Диспетчер серверов как в основной, так и в гостевой операционных системах.
Не оставляйте диспетчер Hyper-V запущенным, так как он постоянно обновляет миниатюру виртуальной машины.
Ниже приведены дополнительные рекомендации по настройке клиента версии Windows на виртуальной машине для снижения общей загрузки ЦП:
Virtual NUMA
Чтобы обеспечить виртуализацию масштабируемых рабочих нагрузок, Hyper-V в Windows Server 2016 расширил пределы масштабирования виртуальных машин. Одной виртуальной машине можно назначить до 240 виртуальных процессоров и 12 ТБ памяти. При создании таких больших виртуальных машин, скорее всего, будет использоваться память нескольких узлов NUMA в хост-системе. В такой конфигурации виртуальной машины, если виртуальные процессоры и память не выделены из одного и того же узла NUMA, рабочие нагрузки могут иметь низкую производительность из-за невозможности воспользоваться преимуществами оптимизации NUMA.
В Windows Server 2016 Hyper-V представляет виртуальным машинам виртуальную топологию NUMA. По умолчанию эта виртуальная топология NUMA оптимизирована для соответствия топологии NUMA базового хост-компьютера. Предоставление виртуальной топологии NUMA на виртуальной машине позволяет гостевой операционной системе и любым приложениям, поддерживающим NUMA, работающим в ней, использовать преимущества оптимизации производительности NUMA, как если бы они работали на физическом компьютере.
С точки зрения рабочей нагрузки нет различий между виртуальным и физическим NUMA. Внутри виртуальной машины, когда рабочая нагрузка выделяет локальную память для данных и обращается к этим данным в том же узле NUMA, быстрый доступ к локальной памяти приводит к базовой физической системе. Снижение производительности из-за удаленного доступа к памяти успешно предотвращается. Только приложения, поддерживающие NUMA, могут использовать преимущества vNUMA.
Microsoft SQL Server является примером приложения, поддерживающего NUMA.
Ваш комментарий будет первым