virtualize cpu performance counters vmware что это

Метрики производительности процессора в утилите esxtop для VMware vSphere. Мы уже касались некоторых аспектов мониторинга производительности с помощью утилиты esxtop, которая есть на сервере VMware ESXi, а также метрик производительности хранилищ (и немного сетевого взаимодействия). Сегодня мы более детально взглянем на метрики производительности процессора (CPU) для контроля нагрузки виртуальных машин. Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным): Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее: Счетчик %RUN Если значение данного счетчика равно x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему. Счетчики %WAIT и %VMWAIT Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN. Когда вы видите высокое значение данного счетчика, это значит, что нужно посмотреть на производительность хранилища виртуальной машины, а также на остальные периферийные устройства виртуального «железа». Зачастую, примонтированный ISO-образ, которого больше нет на хранилище, вызывает высокое значение счетчика. Это же касается примонтированных USB-флешек и других устройств ВМ. Счетчик %RDY Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%. По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение: Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware. Счетчик %CSTP Этот счетчик отображает процент времени, когда виртуальная машина готова исполнять команды, одна вынуждена ждать освобождения нескольких vCPU при использовании vSMP для одновременного исполнения операций. Например, когда на хосте ESXi много виртуальных машин с четырьмя vCPU, а на самом хосте всего 4 pCPU могут возникать такие ситуации с простоем виртуальных машин для ожидания освобождения процессоров. В этом случае надо либо перенести машины на другие хосты ESXi, либо уменьшить у них число vCPU. В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины) %WAIT + %RDY + %CSTP + %RUN = 100% То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).

Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте.

Вебинары VMC о виртуализации:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

Источник

Анализ производительности ВМ в VMware vSphere. Часть 3: Storage

Сегодня разберем метрики дисковой подсистемы в vSphere. Проблема со стораджем – самая частая причина медленной работы виртуальной машины. Если в случаях с CPU и RAM траблшутинг заканчивается на уровне гипервизора, то при проблемах с диском, возможно, придется разбираться с сетью передачи данных и СХД.

Тему буду разбирать на примере блочного доступа к СХД, хотя при файловом доступе счетчики примерно те же.

Немного теории

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

Пропускная способность важна для нагрузок последовательного характера: доступ к блокам, расположенным друг за другом. Например, такую нагрузку могут генерировать файловые сервера (но не всегда) и системы видеонаблюдения.

Пропускная способность связана с количеством операций ввода/вывода следующим образом:

Throughput = IOPS * Block size, где Block size – это размер блока.

Размер блока является довольно важной характеристикой. Современные версии ESXi пропускают блоки размером до 32 767 КБ. Если блок еще больше, он делится на несколько. Не все СХД могут эффективно работать с такими большими блоками, поэтому в Advanced Settings ESXi есть параметр DiskMaxIOSize. С помощью него можно уменьшить максимальный размер блока, пропускаемого гипервизором (подробнее здесь). Рекомендую перед изменением данного параметра проконсультироваться с производителем СХД или хотя бы протестировать изменения на лабораторном стенде.

Большой размер блока может пагубно сказываться на производительности СХД. Даже если количество IOPS и throughput относительно невелики, при большом размере блока могут наблюдаться высокие задержки. Поэтому обращайте внимание на этот параметр.

Latency – самый интересный параметр производительности. Задержка операций ввода/вывода для виртуальной машины складывается из:

GAVG и DAVG измеряются, а KAVG рассчитывается: GAVG–DAVG.

Источник

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

Самой значительной составляющей KAVG является QAVG – время в очереди на обработку внутри гипервизора. Остальные составляющие KAVG пренебрежимо малы.

Очередь в драйвере дискового адаптера и очереди к лунам имеет фиксированный размер. Для высоконагруженных сред данный размер бывает полезно увеличить. Здесь описано, как увеличить очереди в драйвере адаптера (одновременно увеличится очередь к лунам). Данная настройка работает, когда с луном работает только одна ВМ, что бывает редко. Если на луне несколько ВМ, необходимо также увеличить параметр Disk.SchedNumReqOutstanding (инструкция здесь). Увеличив очередь, вы уменьшаете QAVG и KAVG соответственно.

Но, опять же, сначала ознакомьтесь с документацией от вендора HBA и протестируйте изменения на лабораторном стенде.

На размер очереди к луну может влиять включение механизма SIOC (Storage I/O Control). Он обеспечивает равномерный доступ к луну со стороны всех серверов кластера за счет динамического изменения очереди к луну на серверах. То есть, если на каком-то из хостов работает ВМ, которая требует непропорционально много производительности (noisy neighbor VM), SIOC уменьшает длину очереди к луну на данном хосте (DQLEN). Подробнее здесь.

С KAVG разобрались, теперь немного о DAVG. Тут все просто: DAVG – это задержка, которую вносит внешняя среда (сеть передачи данных и СХД). В любой современной и не очень СХД есть свои счетчики производительности. Для анализа проблем с DAVG имеет смысл смотреть на них. Если же со стороны ESXi и СХД все нормально, проверяйте сеть передачи данных.

Чтобы не было проблем с производительностью, выбирайте правильную Path Selection Policy (PSP) для вашей СХД. Практически все современные СХД поддерживают PSP Round-Robin (с ALUA, Asymmetric Logical Unit Access, или без). Данная политика позволяет использовать все доступные пути к СХД. В случае с ALUA используются только пути до контроллера, который владеет луном. Не для всех СХД на ESXi есть дефолтные правила, которые устанавливают политику Round-Robin. Если для вашего СХД правила нет, используйте плагин от производителя СХД, который создаст соответствующее правило на всех хостах кластера, или создайте правило самостоятельно. Подробности здесь.

Также часть производителей СХД рекомендуют менять количество IOPS на путь со стандартного значения 1000 на 1. В нашей практике это позволяло «выжать» из СХД больше производительности и значительно сократить время, которое требуется на failover в случае выхода из строя или обновления контроллеров. Сверьтесь с рекомендациями вендора, и если противопоказаний нет, то попробуйте изменить данный параметр. Подробности здесь.

Основные счетчики производительности дисковой подсистемы виртуальной машины

Счетчики производительности дисковой подсистемы в vCenter собраны в разделах Datastore, Disk, Virtual Disk:

В разделе Datastore находятся метрики по дисковым хранилищам vSphere (датасторам), на которых лежат диски ВМ. Здесь вы найдете стандартные счетчики по:

В разделе Disk находятся метрики по блочным устройствам, которые используются ВМ. Тут есть счетчики по IOPS типа summation (количество операций ввода/вывода за период измерения) и несколько счетчиков, относящихся к блочному доступу (Commands aborted, Bus resets). Данную информацию, на мой взгляд, также удобнее смотреть в ESXTOP.

Раздел Virtual Disk – самый полезный с точки зрения поиска проблем производительности дисковой подсистемы ВМ. Здесь можно посмотреть производительность по каждому виртуальному диску. Именно эта информация нужна, чтобы понять, есть ли проблема у конкретной виртуальной машины. Помимо стандартных счетчиков количества операций ввода/вывода, объема чтения/записи и задержек, в данном разделе присутствуют полезные счетчики, которые показывают размер блока: Read/Write request size.

На картинке ниже график производительности диска ВМ, на котором можно увидеть количество IOPS, задержки и размер блока.

Также метрики производительности можно посмотреть по всему датастору, если включен SIOC. Здесь представлена базовая информация по средней Latency и IOPS’ам. По умолчанию данную информацию можно посмотреть только в реальном времени.

ESXTOP

В ESXTOP несколько экранов, на которых представлена информация по дисковой подсистеме хоста в целом, отдельным виртуальным машинам и их дискам.

Начнем с информации по виртуальным машинам. Экран “Disk VM” вызывается клавишей “v”:

NVDISK – это количество дисков ВМ. Чтобы посмотреть информацию по каждому диску, нажмите “e” и введите GID интересующей ВМ.

Значение остальных параметров на данном экране понятно из их названий.

Еще один полезный при поиске проблем экран – Disk adapter. Вызывается клавишей “d” (на картинке ниже выбраны поля A,B,C,D,E,G):

NPTH – количество путей к лунам, которые видны с данного адаптера. Чтобы получить информацию по каждому пути на адаптере, нажмите “e” и введите название адаптера:

AQLEN – максимальный размер очереди на адаптере.

Также на этом экране представлены счетчики задержек, о которых я рассказывал выше: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

На экране Disk device, который вызывается клавишей “u”, представлена информация по отдельным блочным устройствам – лунам (на картинке ниже выбраны поля A, B, F, G, I). Здесь можно увидеть состояние очереди к лунам.

DQLEN – размер очереди для блочного устройства.
ACTV – количество команд ввода/вывода в ядре ESXi.
QUED – количество команд ввода/вывода в очереди.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Если %USD высокий, стоит рассмотреть возможность увеличения очереди. Чем больше команд в очереди, тем выше QAVG и, соответственно, KAVG.

Также на экране Disk device можно посмотреть, работает ли на СХД VAAI (vStorage API for Array Integration). Для этого нужно выбрать поля A и O.

Механизм VAAI позволяет перенести часть работы из гипервизора непосредственно на СХД, например, зануление, копирование блоков или блокировки.

Как видно на картинке выше, на данной СХД VAAI работает: активно используются примитивы Zero и ATS.

Источник

Оптимизация производительности виртуальных машин VMware Workstation и VMware Server

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

В России наиболее популярными средствами виртуализации являются продукты компании VMware. И это не случайно: VMware, являясь одним из старейших участников рынка, на данный момент является его лидером и во многом определяет направления развития сферы виртуализации в целом. На сегодняшний день наибольший интерес для пользователей представляют коммерческие платформы VMware Workstation, VMware ESX Server и бесплатная платформа VMware Server. Несмотря на то, что VMware Server является серверной платформой, многие пользователи успешно применяют ее в качестве настольной платформы ввиду ее бесплатности, хотя практически по всем параметрам функциональность продукта VMware Workstation 6 намного выше.

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

Сравнительный обзор VMware Server и VMware Workstation

Оптимизация производительности VMware Workstation и VMware Server

Только при соблюдении рекомендаций VMware по оптимизации производительности с учетом этих компонентов можно получить по-настоящему эффективно и быстро работающие виртуальные системы.

Аппаратное обеспечение

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

По оценкам экспертов, большинство серверов на данный момент использует приблизительно 10-20 процентов от аппаратных мощностей компьютеров, поэтому, в этом случае, для продукта VMware Server необходимо придерживаться соотношения 2-4 виртуальные машины на ядро процессора, оставив некоторый запас для пиковых нагрузок на какой-либо из серверов. При использовании VMware Workstation пользователи часто создают десятки виртуальных машин, и число одновременно запущенных виртуальных систем может быть различным, в зависимости от применяемых гостевых ОС.

Хостовая ОС

После того, как память для хостовой платформы будет выбрана, необходимо следить за ее использованием процессами, поддерживающими виртуальные машины. Для того чтобы определить, достаточно ли памяти выделено виртуальным машинам, используйте счетчики ошибок страницы (page faults) и число подкачиваемых страниц в секунду (pages/sec counter). В случае если процессы виртуальных машин интенсивно используют виртуальную память, значения этих параметров будут слишком высоки и виртуальным машинам необходимо будет выделить больше физической оперативной памяти. В операционной системе Windows используйте программу perfmon:
нажмите «Пуск»->«Выполнить»->наберите «perfmon», далее нажмите кнопку «добавить»:

Затем выберите объект «Память» и счетчик «Ошибок страницы/сек» и нажмите кнопку добавить:

В случае если средние значения этого счетчика близки к 100, вам необходимо увеличить память, выделяемую гостевым системам. Более подробную информацию вы можете найти по адресу: http://support.microsoft.com/kb/889654.

Многие сетевые карты могут работать в различных режимах (100 или 1000 МБит/сек, полудуплексном или дуплексном) — убедитесь, что для сетевого интерфейса выставлен наиболее оптимальный режим. Отключите все неиспользуемые физические сетевые интерфейсы. В случае если быстродействие сети для виртуальных машин вас не устраивает, а вы используете только один тип сетевого взаимодействия (например, bridged), можно отключить неиспользуемые виртуальные сетевые адаптеры:

в VMware Workstation или VMware Server в меню «Edit» выберите «Virtual Network Settings», перейдите на вкладку «Host Virtual Adapters» и удалите неиспользуемые адаптеры.

Убедитесь, что включено аппаратное ускорение в хостовых системах Windows. Для этого кликните правой кнопкой на рабочем столе, выберите «Свойства», затем «Параметры», «Дополнительно» и на вкладке «Диагностика» выставьте параметр «Аппаратное ускорение» на максимум.

Платформа виртуализации и виртуальные машины

В случае если ваш процессор использует технологию hyper-threading для представления двух логических процессоров для одного физического, не включайте виртуальный SMP (два виртуальных процессора) в настройках виртуальной машины при ее создании.

Вы можете также вручную выставить приоритет для процессов виртуальных машин:

зайдите в меню «Edit», выберите «Preferences», перейдите на вкладку «Priority» и назначьте приоритет активной виртуальной машине (Input grabbed — когда курсор находится внутри виртуальной машины) и остальным виртуальным машинам в фоне (Input ungrabbed).

Если вы используете хостовую ОС не только для запуска виртуальных машин, но и для других задач вы можете задать количество физической оперативной памяти, которое могут использовать виртуальные машины. Для этого зайдите в меню «Edit», выберите «Preferences», перейдите на вкладку «Memory» и выставьте необходимое количество памяти для виртуальных машин.

Здесь вы можете также определить, как виртуальные машины будут использовать файл подкачки. По умолчанию часть памяти виртуальной машины сбрасывается в файл подкачки. Если же выставить параметр «Allow most virtual machine memory to be swapped», это позволит запустить большее число виртуальных машин одновременно, но отрицательно скажется на их быстродействии. Выбор первого параметра повлечет за собой использование только физической памяти хостовой системы, что ускорит быстродействие, однако, соответственно, уменьшит число одновременно запущенных виртуальных машин.

VMware Workstation и VMware Server используют процедуры очистки неиспользуемой памяти (Memory Trimming). Вообще говоря, этот параметр не сильно влияет на производительность, однако его отключение может немного повысить производительность при работе с дисками виртуальной машины. Отключить его можно, добавив в vmx-файл строчку MemTrimRate=0 или в настройках виртуальной машины:

меню «VM», далее «Settings», вкладка «Options», категорию «Advanced», отметить чекбокс «Disable Memory Page Trimming».

По возможности используйте диски виртуальных машин хранящиеся локально. В случае использования сетевых ресурсов, следите за пропускной способностью сети и ее доступностью. По умолчанию VMware Server и VMware Workstation используют эмуляцию SCSI-дисков. Не меняйте этот параметр, поскольку применение виртуальных IDE-дисков снижает быстродействие. Используйте виртуальные диски типа «preallocated», вместо «growable», хотя вторые и выгодны с точки зрения используемого места (растут по мере наполнения), они работают несколько медленнее. Для задания дисков типа «preallocated» при создании виртуальной машины поставьте галку «Allocate all disk space now». Можно также создавать независимые (Independent) диски для виртуальной машины, которые могут быть постоянными (Persistent) и непостоянными (Nonpersistent). Содержимое этих дисков существует независимо от мгновенных снимков виртуальной машины (снапшотов). Непостоянные диски отличаются тем, что их содержимое сбрасывается при выключении виртуальной машины. Диски типа Independent-persistent обладают наилучшим быстродействием и рекомендуются для большинства вариантов использования. Для того чтобы создать такой диск, выберите меню «VM», «Settings», на вкладке «Hardware» выберите диск и нажмите «Advanced», убедитесь, что галки «Independent» и «Persistent» установлены.

Многие забывают, что некоторые старые операционные системы, такие как Windows 98, постоянно проверяют наличие диска в приводе, что приводит к потере быстродействия. Виртуальный CD/DVD-ROM можно отключить в настройках виртуальной машины:

меню «VM», далее «Settings», выберите категорию CD-ROM и снимите галки «Connected» и «Connect at power on».

Гостевая ОС и приложения

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

Внутри виртуальной машины необходимо так же отслеживать интенсивность использования виртуальной памяти, как и для хостовой системы, используя счетчики «Ошибок страницы» и «Ошибок страницы/сек» для того, чтобы определить, достаточно ли памяти выделено виртуальной машине. Чтобы выяснить насколько интенсивно отдельное приложение использует виртуальную память, в программе perfmon добавьте счетчик для объекта «Процесс» и выберите его из списка справа:

В гостевой и хостовой системах Windows дефрагментацию дисков можно производить либо с помощью встроенной утилиты defrag, либо с помощью программ сторонних производителей. Дефрагментация файлов виртуальных дисков может быть проведена с использованием платформы виртуализации. Выберите меню «VM», «Settings», на вкладке «Hardware» выберите диск и нажмите кнопку «Defragment»:

Убедитесь, что гостевая система использует подходящий драйвер сетевой карты, для этого в Windows посмотрите свойства сетевой карты в диспетчере устройств. При установленных VMware Tools, в качестве драйвера должен быть установлен VMware Accelerated Driver:

Заключение

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

Источник