Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 1)

• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 3)
• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 4)
• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 5)
• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 6)

Введение

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

Медленно - субъективный термин

Первое, что вы должны понять об устранении неполадок с производительностью виртуальной машины, это то, что слово «медленный» является субъективным термином. Слово медленный может означать разные вещи для разных людей. Всякий раз, когда кто-то говорит мне, что виртуальная машина работает медленно, я первым делом спрашиваю: «медленнее по сравнению с чем»? Работает ли виртуальная машина медленнее, чем если бы она работала на выделенном оборудовании? Он работает медленнее, чем вчера? Он работает медленнее, чем 386, который у меня был в колледже?

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

Насколько широко распространена проблема?

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

Базовое сравнение

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

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

Первое, что вам нужно понять о мониторинге производительности виртуальной машины, это то, что данные о производительности искажаются гипервизором. Чтобы показать вам, как это работает, давайте представим, что хост-сервер содержит четыре ядра ЦП, а виртуальная машина снабжена одним ядром ЦП. Теперь давайте представим, что вы запустили монитор производительности и определили, что виртуальная машина использует 100% ресурсов процессора. Это не означает, что ресурсы ЦП хост-сервера исчерпаны. Это означает лишь то, что виртуальная машина использует все выделенные ей ресурсы ЦП. В этом упрощенном примере виртуальная машина использует 100% одного виртуального ядра ЦП. Поскольку хост имеет четыре ядра ЦП, это означает, что виртуальная машина использует 25% всех ресурсов ЦП хоста.

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

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

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

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

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

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

Вывод

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

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

• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 3)
• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 4)
• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 5)
• Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 6)