Какие счетчики нас интересуют и пороговые значения

Сначала  приведу сводную таблицу самых важных счетчиков, пороговых  значений их показаний и краткое  описание  (табл. 6.1). Затем последовательно коснусь нюансов каждой из подсистем сервера в случае виртуализации и более подробного описания  счетчиков.

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

Мониторинг достаточности ресурсов

Таблица 6.1. Важные счетчики и их пороговые значения

Подсистема

Счетчик

Значение

Описание, возможная причина проблемы

CPU

%RDY

10*

кол-во vCPU

Очередь к процессору. ВМ не хватает ресурсов процессора

CPU

%CSTP

3

Накладные расходы на многопроцессорную ВМ. Уменьшите число vCPU этой ВМ, или число vCPU на сервере где она работает

CPU

%MLMTD

0

Если больше 0, то возможно ВМ уперлась в Limit по процессору

CPU

%SWPWT

5

ВМ ожидает чтения страниц из файла подкачки. Возможно, ВМ не хватает физической памяти

MEM

MCTLSZ (I)

1

Если больше 0, значит механизм Balloon отнимает память у гостевой ОС

MEM

SWCUR (J)

1

Если больше 0, значит часть памяти ВМ в файле подкачки VMkernel

MEM

CACHEUSD

1

Если больше 0, значит часть памяти ВМ отнимается механизмом memory compression

MEM

ZIP/s

0

Если больше 0, значит ВМ использует память в кэше memory compression

MEM

UNZIP/s

0

Если больше 0, значит ВМ использует память в кэше memory compression

MEM

SWR/s (J)

1

Чтение из файла подкачки. Если больше 0, значит файл подкачки используется

MEM

SWW/s (J)

1

Запись в своп-файл. Если больше 0, значит своп-файл используется

DISK

GAVG (H)

25

Задержки для гостевой ОС. Это сумма счетчиков «DAVG» и «KAVG»

DISK

DAVG (H)

25

Задержки устройства хранения. Высокое значение этого счетчика говорит о задержках со стороны системы хранения

DISK

KAVG (H)

2

Задержки на уровне гипервизора

DISK

ABRTS/s

1

Отказы инициированные гостевой ОС (ВМ) из за того, что СХД не отвечает. Для Windows это происходит через 60 секунд, по умолчанию. Могут быть вызваны отказом путей к LUN, или проблемами в работе multipathing

DISK

QUED (F)

1

Превышена величина очереди команд

DISK

RESETS/s (K)

1

Число сброса SCSI команд в секунду

DISK

CONS/s

20

Число конфликтов SCSI reservation в секунду. Если происходит слишком много конфликтов, производительность СХД может деградировать из за потерь времени вследствие резервирования LUN то одним, то другим сервером

NET

%DRPTX

1

Отброшенные передаваемые пакеты. Возможно, сеть перегружена

NET

%DRPRX

1

Отброшенные принимаемые пакеты. Возможно, сеть перегружена

CPU

Итак,  мы  столкнулись с  недостаточной производительностью сервера.  Не в процессоре  ли дело? Если  речь идет о физическом сервере, то самый простой путь – это открыть Task Manager и посмотреть на загрузку процессора (рис. 6.51).

Однако что означает 100%-ная загрузка процессора?

Формально она означает следующее: на этом процессоре нет свободных тактов, на которых работает процесс idle (бездействие системы).  В случае работы ОС на физическом сервере это обычно и означает, что ресурсов процессора недостаточно.

Рис. 6.51. Менеджер процессов нагруженного сервера

В случае же виртуальной машины  гостевая  ОС не имеет доступа к управлению ресурсами физических процессоров. Управляет доступом к ним гипервизор,  и именно гипервизор  выделяет  или не выделяет процессорное  время для ВМ.

Таким образом, 100%-ная загрузка процессора внутри ВМ означает, что гостевая ОС не видит свободных тактов процессора.  Но не факт, что их нет на физи ческом процессоре,  – может быть, их гипервизор  не показывает,  а выдает ровно столько процессорного времени, сколько готова задействовать гостевая ОС.

Определять же, хватает  ли процессорных тактов  ВМ или  же гипервизор  ей достаточно не выдает, нужно по-другому. Основных путей два – воспользоваться закладкой Perfomance для ВМ в клиенте vSphere или консольной утилитой esxtop (resxtop в случае использования vSphere CLI).

Какие счетчики  нам доступны?  Фактически ВМ для гипервизора – это как процесс для обычной операционной системы. И счетчики очень похожие. Основные здесь:

Q  usage – сколько  процессорных ресурсов  ВМ задействовала. Выполненная

работа. Не с точки зрения  гостевой ОС, а с точки зрения гипервизора.  Доступен в разных единицах измерения,  смотря где мы и как смотрим показания этого счетчика. Может показываться в мегагерцах, процентах (от производительности одного LCPU) и миллисекундах (процессорного времени);

Q  wait – столько времени заняло ожидание ввода/вывода;

Q  ready  – самый  важный  в данном  контексте  счетчик.  Он  показывает,  на сколько процессорного времени у ВМ осталось несделанной  работы.

Мониторинг достаточности ресурсов

В каждый момент времени ВМ готова выполнить какую-то работу. Эта работа делится на сделанную и несделанную, или CPU  usage и CPU  ready. Именно высокий показатель  CPU  ready говорит о том, что ВМ не хватает ресурсов процессора, – работа у ВМ есть, но гипервизор  под нее не выделяет процессор.

Теперь поговорим про то, почему CPU  ready может быть высокий и как с этим

бороться.

Вернитесь к рис. 6.40.

На графике  мы видим, что за последний  квант времени мониторинга процессор номер 0 этой ВМ:

Q  Usage – выполнял полезную работу 4351 миллиcекунду;

Q  Wait – 14 873 миллиcекунды процессор  находился  в состоянии wait, то есть  ожидания   окончания процессов  ввода/вывода. Вывод:  у этой  ВМ проблемы  со скоростью  доступа  к дискам  или  к сети.  Как  мониторить диски  и сеть – далее. Также  есть отдельный  счетчик  swap wait  time. Он показывает  ожидание  операции  с файлом  подкачки VMkernel.  Это время входит в wait;

Q  Ready – гостевая ОС хотела выполнить работу, но гипервизор не дал достаточно процессорного времени на это – еще 930 миллисекунд. Вывод – для этой ВМ не хватает процессорных ресурсов как таковых.

Обратите внимание. В CPU Ready показывается сумма этого показателя для всех процессоров виртуальной машины. То есть CPU Ready = 20 для четырехпроцессорной ВМ может означать очередь CPU Ready = 5 для каждого из процессоров, что является нормальным. Но возможно,  что проблемы у какого-то одного виртуального процессора. Чтобы определить  это, просмотрите данные по каждому процессору.

Таким образом, почему CPU ready может быть высоким? Вариантов, в общемто, несколько.

Во-первых,  возможно,  что ресурсов  процессора  сервера в принципе недостаточно на все ВМ. Наша  ВМ претендует  на какую-то  долю в соответствии с настройками  reservation и shares, но этой доли ей не хватает.

Решение – увеличить количество  доступных ресурсов. Это можно сделать:

Q  выключив или перенеся на другие серверы часть ВМ;

Q  перенеся на более свободный сервер эту ВМ;

Q  увеличив  ее reservation или shares;

Q  понизив reservation или shares других ВМ.

Частный  случай предыдущего пункта – когда на самом сервере свободные ресурсы есть, но не хватает ресурсов в пуле ресурсов, где работает эта ВМ.

Решение:

Q  те же варианты, что и в предыдущем списке;

Q  увеличить долю ресурсов этого пула;

Q  понизить  долю ресурсов других пулов.

Еще один частный случай – на самом сервере ресурсов процессора в достатке, но ВМ не хватает всех тех ресурсов, что гипервизор  может ей дать. Напомню, что один vCPU работает на одном, и только на одном LCPU.  Это значит, что однопро-

цессорная  ВМ как максимум  может задействовать ресурсы одного ядра сервера. Двухпроцессорная – двух ядер и т. д. Получается, что если ВМ, например,  однопроцессорная и приложению не хватает той производительности, что может дать одно ядро, вы получите высокий CPU ready.

Решение  – дать ВМ больше виртуальных процессоров.  Какие нюансы могут

здесь нас поджидать:

Q  в одной ВМ может быть не больше восьми vCPU,  когда ESX(i) имеет Enterprise  Plus лицензию. И не больше четырех во всех других, включая  бесплатную лицензию, случаях;

Q  приложение в ВМ должно  быть многопоточным,  чтобы получилось вос-

пользоваться вторым и далее vCPU;

Q  используемая в ВМ ОС или приложение могут иметь собственные ограничения  на количество  поддерживаемых процессоров. Возможна  ситуация,  когда с точки зрения  ESX(i) мы можем выдать 8 (например) процессоров  для ВМ, а ПО внутри не может их задействовать из-за своих технических  или лицензионных ограничений.  Это можно обойти  с помощью экспериментальной настройки в файле настроек (*.vmx) ВМ:

cpuid.coresPerSocket  =  X

где X – это число ядер в сокете виртуальной машины. Таким образом, если X = 2 и число процессоров в ВМ = 8, то гостевая ОС увидит не 8 одноядер ных процессоров, а 4 двухъядерных;

Q  еще одна потенциальная причина  того, что ВМ не выделяются такты, хотя

они и есть свободные,  – это настройка  limit  для процессоров  ВМ. Решение – увеличить limit.

Из общих рекомендаций следует отметить следующую – всегда настраивайте ВМ на использование  как можно меньшего  количества виртуальных процессоров. Только  если вы однозначно  уверены, что не хватает именно производительности одного физического ядра, то выдавайте  ВМ второй  (и т. д.) виртуальный процессор.  Убедитесь,  что производительность действительно увеличилась. Эта рекомендация является следствием того, что с ростом числа vCPU для ВМ уменьшается эффективность их использования и растут накладные  расходы.

Приведенные здесь рекомендации по решению проблем  с производительностью для процессора  являются самыми простыми. Существуют  и более глубокие методики, типа настройки ОС и приложений на использование больших страниц памяти или снижение частоты timer interrupt для гостевой ОС. Здесь я их не привожу в силу их большей зависимости от конкретного случая, конкретной гостевой ОС и прочего, так что см. документацию. Например, рекомендую обратиться к документу «Performance Troubleshooting for VMware vSphere 4» (http://communities. vmware.com/docs/DOC-10352).

MEMORY

Для оперативной памяти показателем недостаточности ресурсов является вытеснение виртуальной машины из памяти сервера в файл подкачки. Главный нюанс заключается в том, что использование VMkernel Swap, memory compression  и

Мониторинг достаточности ресурсов

balloon изнутри ВМ определить невозможно. Поэтому опять же необходимо смотреть «снаружи», со стороны гипервизора.

Выделите  ВМ ? закладка  Perfomance ? Chart Options. В левой части от-

крывшегося окна выберите Memory и интересующий период времени. Справа до-

ступны счетчики:

Q  Consumed – столько памяти для ВМ выделено из физической памяти сервера;

Q  Granted – это количество  памяти  сервер  выделил  для  ВМ. Страница не выделяется, пока со стороны ВМ не будет хотя бы одного запроса для нее. Выданные страницы  могут быть отобраны механизмами vmmemctl и VMkernel swap;

Q  Active – с такого объема памятью ВМ активно работала в момент последнего опроса. Выделенная, но не активная память может быть отобрана у ВМ без ущерба для ее производительности;

Q  Balloon – столько памяти отнимается  у ВМ механизмом balloon;

Q  Zipped memory – столько памяти находится в сжатом виде, в буфере механизма memory compression;

Q  Swapped – столько памяти помещено в VMkernel  swap;

Q  Swap in rate и Swap out rate – активность  использования файла подкачки.

Даже большие  значения  в balloon и swapped могут не означать проблемы производительности  конкретной   ВМ  – этими  механизмами  гипервизор  может отнимать у ВМ память, которую та в данный момент не использует. А нужна ли ВМ та память, что ESX(i) этими механизмами отбирает, показывают данные счетчики.

Таким  образом, свидетельством нехватки  памяти  являются стабильно высокие показатели balloon, zipped и swapped вкупе с высокими показателями Swap in rate и Swap out rate.

DISK

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

1.    Гостевая ОС общается с драйвером SCSI контроллера (виртуального).

2.    Он передает команды SCSI-контроллеру.

3.    Они  перехватываются гипервизором, гипервизор  формирует очередь команд из обращений к диску своих ВМ и передает ее драйверу контроллера. Это может быть драйвер HBA, или служба NFS, или программный iSCSI инициатор.

4.    В зависимости от варианта  эти команды  быстрее или чуть медленнее попадают на контроллер, HBA или NIC.

5.    Запрос уходит на систему хранения  и затем в обратном порядке возвращается к гостевой ОС.

Обычно  узким местом становится этап № 4 или 5. В каких-то  ситуациях мы можем  упереться  в пропускную  способность  канала  передачи  данных. В каких-

то – в количество  операций  ввода/вывода, которые способна обработать система хранения.

Если вернуться  к таблице важных счетчиков, то для дисковой подсистемы:

Q  GAVG – это этапы со второго по пятый;

Q  KAVG – это этапы три и четыре;

Q  DAVG – это этап пять.

Данные по нагрузке на дисковую подсистему  нам могут предоставить клиент vSphere,  esxtop  и утилита  vscsiStats.  Последняя предоставляет более детальные и низкоуровневые данные.  Подробная информация о  ней приведена  по ссылке http://communities.vmware.com/docs/DOC-10095.

В крупных инфраструктурах часто имеет смысл обращаться  к статистике  нагрузки со стороны системы хранения.  СХД высокого уровня имеют соответству ющие возможности.

В инфраструктурах любого размера внимательно изучайте документацию по настройке имеющейся СХД под ESX(i) – проблемы производительности из-за неправильной настройки чрезвычайно обидны.

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

Network

Для сети нас в первую очередь интересует  количество  отброшенных пакетов.

Это счетчики droppedRx и droppedTx в графическом интерфейсе, или %DRPTX и

%DRPRX в esxtop.

Высокие  показатели этих  счетчиков  свидетельствуют о плохой  производи тельности сети.

Однако в большинстве  случаев проблемы с производительностью сети вызваны внешней относительно серверов ESX(i) частью инфраструктуры.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий