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

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

Более 4810 заметок о виртуализации и виртуальных машинах 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 и не скем не конфликтуют >следовательно> заметное влияние оказывать не должны.
Реклама







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

29/05/2019:  IT&SECURITY FORUM 2019
05/06/2019:  IT Management Forum 2019
06/06/2019:  VeeamON Forum 2019

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

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

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

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

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

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

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

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

Работа с дисками виртуальных машин VMware.

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

Новые возможности 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 - 2019, Александр Самойленко. Правила перепечатки материалов.