Sdílet prostřednictvím

Hyper-V и производительность. Часть 2 — счетчики производительности. Где правда?

  • Článek

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

Мы уже знаем, что Hyper-V имеет родительскую (основную, root, host в разной терминологии) операционную систему и гостевые (guest) ОС в виртуальных машинах. Родительская ОС работает с большинством устройств напрямую, в ней устанавливаются драйверы; в ней же существуют Virtual Service Providers, которые предоставляют доступ к устройствам для гостевых ОС, через их Virtual Service Clients. В архитектуре процессоров x86, однако, существуют элементы, к которым невозможно предоставлять совместный доступ. Таким образом, они не могут находиться под контролем родительской ОС, и гипервизор эмулирует эти элементы как для родительской, так и для гостевых ОС. Примером такого элемента является таймер, на основе которого, в частности, в компьютере работают часы.

Теперь рассмотрим один из важнейших наборов счетчиков производительности Windows — % Processor Time. Эти счетчики показывают суммарный процент загрузки процессора (есть ли свободные ресурсы для выполнения задач без ожидания в очереди) и процент загрузки процессора конкретным процессом (например, насколько интенсивно Microsoft Word 2009 использует процессор пока я пишу данную заметку для блога).

А теперь рассмотрим эти счетчики одновременно из родительской и гостевой ОС, заметим разницу в показаниях и выясним, кто прав, а кто врёт. Картинка ниже отражает ситуацию, когда в виртуальной машине я запустил программу, генерирующую стопроцентную загрузку процессора. Performance Monitor в гостевой ОС реально показывает загрузку процессора в 100%. Однако, в это же время в родительской ОС я вижу загрузку процессора в 85% в счетчике Hyper-V Hypervisor Guest Run Time для конкретной виртуальной машины.

Итак, кто же прав? Как ни странно — оба. Гостевая ОС использует 100% процессорных ресурсов, предлагаемых ей гипервизором, и все процессорное время, отданное данной гостевой ОС тратится на вычислительную задачу, генерирующую стопроцентную загрузку виртуального процессора.

При этом, счетчик Hyper-V Hypervisor Guest Run Time показывает загруженность физического процессора данной гостевой ОС. Именно в этом и есть отличие. Если вы измеряете нагрузку, которую оказывает ваша виртуальная машина на реальные ресурсы сервера, вам следует пользоваться счетчиками в родительской ОС. Если вас интересует загрузка виртуального процессора неким приложением в гостевой ОС, тогда следует измерять производительность именно в виртуальной машине. Цифры будут разными, так как отражают разные понятия — физический и виртуальный процессор.

Comments

  • Anonymous
    January 01, 2003
    Это ни для кого не секрет. Microsoft обещает выпускать офисные продукты раз в три года. Office 2007 стал доступен volume заказчикам в ноябре 2006 (а сотрудникам летом 2006). Значит через год у нас будет установлен финал 2009. Ближайшей осенью нас ждет Service Pack 2 для Office 2007, ориентироваться заказчикам сейчас следует на него, а не на еще не вышедший даже в широкое бета тестирование продукт. Я же всегда сидел на предварительных версиях и ОС, и офис..

  • Anonymous
    January 01, 2003
    Денис, я уточнил, есть жесткое ограничение на 50 снапшотов для VM. То есть если вам нужны снапшоты, придется написать скрипт, который будет удалять старые. Так, например, чтобы хранились все старые - раз в месяц, плюс по одному за каждый день последней недели + раз в час за последний день. На PowerShell делается несложно, нужно лишь оттестировать будет скрипт.

  • Anonymous
    January 01, 2003
    Техническое ограничение сделано как раз из-за того, что диски дифференциальные. Возникают длинные цепочки, которыми сложно управлять. Увы, быстро сделать инкрементальный образ (не от последнего, а от базового образа) невозможно, - потребуется время на его генерацию, потому и выбраны дифференциальные диски. Партнерам на откуп отдан SDK, кто-то может (например вы) изменить это значение (в разумных пределах, скажем до 255). Но это выйдет за рамки поддерживаемой конфигурации, так что предлагаемый мной подход со скриптом будет оптимален. Если напишите скрипт и вам будет его не жалко, можно будет запостить для аудитории, думаю что много кому это интересно.

  • Anonymous
    January 01, 2003
    Абсолютно нетрудоемок. Вопрос в необходимости и производительности длинных цепочек дифференциальных дисков. Не уверен, что количество звеньев в цепочке неограничено. Еще помните, что снимки сохраняются не параллельно, а последлвательно.

  • Anonymous
    July 02, 2008
    про 2009 Word - это серьезно? in next year? )

  • Anonymous
    July 02, 2008
    Понятно, спасибо. Еще есть вопрос про производительность. Скажите, насколько для физ.и вирт. машин трудоемок процесс сохранения снимков, к примеру раз в час или чаще даже? Пример: мощний сервер с 4-я ВМ, каждая делает снимок каждые пол часа. Спасибо.

  • Anonymous
    July 03, 2008
    Спасибо, пишу скрипт. Интересно, с чем связано тех. ограничение, ведь вполне могли одать вопрос на откуп заказчику, т.е. на его дисковые ресурсы.