Более 1140 статей и записок о виртуализации, виртуальных машинах VMware, Microsoft, Citrix, Red Hat, Parallels, а также Cloud Computing
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).
Чрезмерное использование 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
Задержки диска, вызванные, скорее всего, со стороны массива.
Отмена команды SCSI, вызванная гостевой ОС виртуальной машины, вследствие того, что система хранения не отвечае. Для гостевых ОС Windows это случается по умолчанию через 60 секунд. Может случиться, например, при отказе пути в SAN.
DISK (кнопка d)
RESETS/s (K)
1
Число сброса SCSI-команд (commands reset) в секунду.
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 и не скем не конфликтуют >следовательно> заметное влияние оказывать не должны.
RSS
