Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4360 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru / Articles / Производительность сервера VMware ESX и виртуальных машин - решение проблем с помощью esxtop и resxtop.

Производительность сервера VMware ESX и виртуальных машин - решение проблем с помощью esxtop и resxtop.

Производительность сервера VMware ESX и виртуальных машин - решение проблем с помощью esxtop и resxtop.

Автор: Александр Самойленко
Дата: 13/01/2010

Реклама:



Статья:

Зачастую бывает необходимо понять причины, по которым та или иная виртуальная машина на сервере VMware ESX испытывает проблемы производительности (тормозит). Можно воспользоваться встроенными графиками производительности VMware vCenter (вкладка Performance), однако этого может оказаться недостаточно. В консольной ОС VMware ESX (Service Console) есть утилита esxtop, которая позволяет отслеживать все аспекты производительности сервера виртуализации, а для VMware ESXi доступна утилита resxtop, которую можно запустить с помощью VMware vSphere Management Assistant.

Известный блоггер, Duncan Epping, недавно опубликовал у себя таблицу различных параметров команды esxtop, смотря на значения которых можно идентифицировать проблему производительности на сервере VMware ESX. В таблице ниже приведены наименования счетчиков, величины пороговых значений, которые они обычно не должны превышать, и объяснения возможных причин проблем производительности и тормозов сервера ESX и виртуальных машин.

Чтобы вызвать утилиту esxtop, необходимо набрать в консоли VMware ESX команду:

esxtop

Далее можно переключаться на различные аспекты просмотра счетчиков, нажимая кнопки на клавиатуре:

m - информация об использовании памяти

n - параметры сетевого взаимодействия (здесь о просмотре балансировки нагрузки на интерфейсы)

d - информация о дисковой подсистеме (кроме того, можно использовать утилиту vscsiStats)

Вид esxtop Счетчик (метрика) Пороговое значение Причины и особенности превышения порога
CPU (основной вид, кнопка c) %RDY 10

Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready-to-run), но ожидает в очереди, пока процессор(ы) сервера ESX занят(ы) другой задачей (ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU).

По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:

- сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)

- большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU ready. Кроме того, когда нужен co-sheduling нескольких виртуальных vCPU, должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU).

Смотрите также объяснение Jason'а Boche. Кроме того, может быть превышено при установленном значении CPU Limit (см. счетчик %MLMTD). Также посмотрите вот этот документ VMware.

CPU (основной вид, кнопка c) %CSTP 100 Чрезмерное использование vSMP (виртуальных CPU для ВМ). Уменьшите число vCPU для данной ВМ, но это приведет к большему количеству отложенных команд.
CPU (основной вид, кнопка c) %MLMTD 0

Если значение больше 0, то виртуальная машина, скорее всего, упирается в CPU Limit, выставленный в настройках виртуальной машины или пула ресурсов.

CPU (основной вид, кнопка c) %SWPWT 1 Виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска. Возможная причина - memory overcommitment.
MEM (кнопка m) MCTLSZ (I) 1

сли значение больше 0, то хост ESX начал вызывать в гостевой ОС виртуальной машины balloon driver, который передает неиспользуемую память виртуальной машины другим ВМ с большой загрузкой памяти (техника memory overcommitment). Возможно, нужно поэкспериментировать с расширенной хоста ESX настройкой Mem.CtlMaxPercent, которая отвечает за максимально возможный относительный объем изымаемой у гостевой ОС памяти.

MEM (кнопка m) SWCUR (J) 1

Если значение больше 0, то хост ESX складывал страницы памяти в файл подкачки (swap) в прошлом. Причина - memory overcommitment.

MEM (кнопка m) SWR/s (J) 1 Если значение больше 0, то виртуальные машины активно ведут чтение из файлов подкачки (vswp). Причина - нехватка памяти вследствие чрезмерного memory overcommitment.
MEM (кнопка m) SWW/s (J) 1

Если значение больше 0, то виртуальные машины активно ведут запись в файлы подкачки (vswp). Причина - нехватка памяти вследствие чрезмерного memory overcommitment.

NETWORK (кнопка n) %DRPTX 1 Число "дропнутых" пакетов на передачу. Возникает, скорее всего, из-за очень высокого использования сетевых интерфейсов виртуальными машинами. Необходимо увеличение пропускной способности сети.
NETWORK (кнопка n) %DRPRX 1

Число "дропнутых" пакетов на прием. Возникает, скорее всего, из-за очень высокого использования сетевых интерфейсов виртуальными машинами. Необходимо увеличение пропускной способности сети.

DISK (кнопка d) GAVG (H) 25 Это сумма счетчиков "DAVG" и "KAVG".
DISK (кнопка d) DAVG (H) 25 Задержки диска, вызванные, скорее всего, со стороны массива.
DISK (кнопка d) KAVG (H) 5

Задержки диска, вызванные микроядром VMkernel сервера ESX. Необходимо проверить счетчик "QUED".

DISK (кнопка d) QUED (F) 1

Превышены величина очереди SCSI-команд. Возможно выставлена слишком маленькая величина очереди и необходимо ее увеличить в соответствии с рекомендациями производителя массива для серверов с VMware ESX / ESXi (для Fibre Channel массивов). Для массивов iSCSI (s/w и h/w) настройки инициаторов приведены здесь.

DISK (кнопка d) ABRTS/s (K) 1

Отмена команды SCSI, вызванная гостевой ОС виртуальной машины, вследствие того, что система хранения не отвечае. Для гостевых ОС Windows это случается по умолчанию через 60 секунд. Может случиться, например, при отказе пути в SAN.

DISK (кнопка d) RESETS/s (K) 1 Число сброса SCSI-команд (commands reset) в секунду.

Обратите также внимание вот на этот документ: Interpreting esxtop Statistics. Он же в хтмл: http://communities.vmware.com/docs/DOC-9279



Комментариев: 12
voron70 (09/01/2010)
По моему тут опечатка, счетчики GAVG,DAVG,KAVG вида DISK вызываются кнопкой J, а не H
voron70 (10/01/2010)
По моему тут опечатка, счетчики GAVG,DAVG,KAVG вида DISK вызываются кнопкой J, а не H
areconster (10/01/2010)
Спасибо. К сожалению, сейчас не могу посмотреть. Поправлю как смогу.
nyh (13/01/2010)
"%CSTP - Чрезмерное использование vSMP (виртуальных CPU для ВМ)." Если не ошибаюсь, этот счетчик показывает время которое затрачивается на синхронизацию vпроцессоров (co-scheduling). И это лишь косвенно связанно с нагрузкой на сами процессоры.
areconster (13/01/2010)
To nyh. Совершенное верно, поэтому если будет меньше виртуальных CPU, время будет меньше. Соответственно, рекомендация - уменьшить число vCPU. Кстати, добавил вот этот интереснейший документ - http://www.gronau.it/index2.php?option=com_content&do_pdf=1&id=508
deniszh (14/01/2010)
To areconster Имхо Interpreting esxtop Statistics приятнее читать в HTML и в оригинале - http://communities.vmware.com/docs/DOC-9279 Кстати. Кто нибудь знает как получить метрики ESXTOP в неинтерактивном виде, для целей анализа и мониторинга?
Major (11/02/2010)
В статье есть ошибка (описание счетчика %RDY) Для выполнения команд нескольких vCPU (отданых одной vHost) нет необходимосте ждать освобождения всех физических CPU, более того, команды нескольких vCPU могут выполняться на одном CPU. Виртуальные процессоры гипервизор видит как обычные пайпы Fi-Fo (unix pipe), из которых планировщик гипервизора читает блоки процессорных инструкций и отправляет их на выполнение. При этом НИ О КАКОЙ ОДНОВРЕМЕННОСТИ (синхронности) не может быть и речи. Сохраняется только порядок выполнения считанных блоков инструкций, для этого действительно с каждым vCPU ассоциируется один CPU(ядро) но в процессе работы планировщик ESXа может перемещать поток инструкций на др. CPU (при этом соблюдается условие: одновременно не может выполняться несколько блоков инструкций с одного vCPU) Еслибы это было не так, то создание на машине с Одним одноядерном процессором гостевой системы с несколькими vCPU было бы невозможно. Рост CPU Ready и падение производительности обусловлено другим: Предположим что мы имеем vHost с 4мя vCPU, против 2 реальных CPU - значит за 1 квант времени смогут отработать 2 vCPU (из их очередей будет считано по пачке инструкций) а 2 других будут ждать, и выполнятся в следующий квант >следовательно> одна распаралелленая операция (средствами гостевой оси)будет выполнена за вдвое больший срок (при этом не производительность упадет в 2 раза, а в 2 раза вырастет latensy (задержка/инерционность) оси. Оффтоп: А выполнять чтолибо одновременно на нескольких различных железках (пусть даже на соседних ядрах) технически НЕВОЗМОЖНО на универсальных процессорах (тут виноват и кэш и спекулятивная выборка и буферы переупорядочивания команд...). Этот фокус проходит только на DSP процессорах.
areconster (11/02/2010)
Большое спасибо за объяснение! Про то, что команды с разных vCPU могут выполняться на одном pCPU я знал, но ввела в заблуждение фраза: When co-scheduling for n-way Virtual SMP is required, the virtual CPUs can be scheduled only when n physical CPUs are available to be preempted. Статью поправим, я не слишком силен в логике работы железа) Кстати, а когда co-scheduling for n-way Virtual SMP is required?
areconster (11/02/2010)
Обновлено
Major (12/02/2010)
http://www.vmware.com/vmtn/resources/240- В этой статье достаточно хорошо объяснены особенности работы VMware Virtual SMP. ИСХОДЯ ИЗ СТАТЬИ: co-scheduling действительно может вызывать блокировки (если в пачках инструкций различных vCPU есть связь по данным/управлению или если используются конструкции с синхронизаций по времени (для реализации "реального времени")) - тогда и возникает "...Virtual SMP is required". НО ИЗ ЖИЗНИ: если на 1CPU (и с HT и без) можно запустить vHost с vSMP (можно, проверял) то выход инженерами VMWare был найден. Хотя при этом производительность может падать фантастически. Это значит что блокировки есть, но они не столь категоричны как это написано в большинстве источников. И последнее (моё личное мнение): блокировки vSMP довольно редки, т.к. у распаралелливаемых задач зависимости минимизированы (это принцип паралеллизации) а неделимые задачи грузят одно pCPU и не скем не конфликтуют >следовательно> заметное влияние оказывать не должны.
areconster (12/02/2010)
Спасибо. Ну значит вроде разобрались) Если обобщить получается, что удельная производительность виртуального процессора машины в случае однопроцессорной виртуальной машины больше, чем удельная производительность vCPU многопроцессорной машины. Это факт зафиксирован в различных документах VMware. Еще раз спасибо за помощь!
Major (12/02/2010)
http://www.vmware.com/vmtn/resources/240- В этой статье достаточно хорошо объяснены особенности работы VMware Virtual SMP. ИСХОДЯ ИЗ СТАТЬИ: co-scheduling действительно может вызывать блокировки (если в пачках инструкций различных vCPU есть связь по данным/управлению или если используются конструкции с синхронизаций по времени (для реализации "реального времени")) - тогда и возникает "...Virtual SMP is required". НО ИЗ ЖИЗНИ: если на 1CPU (и с HT и без) можно запустить vHost с vSMP (можно, проверял) то выход инженерами VMWare был найден. Хотя при этом производительность может падать фантастически. Это значит что блокировки есть, но они не столь категоричны как это написано в большинстве источников. И последнее (моё личное мнение): блокировки vSMP довольно редки, т.к. у распаралелливаемых задач зависимости минимизированы (это принцип паралеллизации) а неделимые задачи грузят одно pCPU и не скем не конфликтуют >следовательно> заметное влияние оказывать не должны.
Реклама



Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

06/03/2018:  ИТ-стратегия 2018
24/05/2018:  IT&SECURITY FORUM (Казань)

Быстрый переход:
IT-Grad VMware Cisco StarWind Veeam vGate Microsoft Cloud SDRS Parallels IaaS Citrix 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn Security Code 1cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vCloud Tools vCSA vSAN Horizon Networking esxtop VVols HA Backup Book Photon VMworld vROPs Labs Fusion Cloud Computing SSD Client DRS OpenStack Comparison Workstation Blast SRM App Volumes Performance Manager Nested AWS Log Insight XenDesktop VSA vNetwork SSO LSFS Workspace Host Client VMDK VTL Update iSCSI SDDC NSX Agent Virtual Appliance Whitepaper PowerShell Appliance VUM V2V Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Vanguard SaaS Connector Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Converter XenApp Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Director Migration Diagram Bug Troubleshooting Air API CLI Plugin DPM Memory Upgrade SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер 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 ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.