В продолжении заметки о доступных к мониторингу счетчиках хотелось бы уменьшить список счетчиков на которые необходимо в первую очередь обращать внимание при troubleshooting.
- Первое что стоит понимать количество ядер процессора физического сервера будет меньше суммарного количества vCPU виртуальных машин "находящихся" на этом сервере, от этого я возникает ряд специфических для виртуализации проблем с производительностью.
- 1 vCPU = 1 vCore = 1 Core
- Для большинства случаев на серверах стоит включать hyper-threading.
- Включайте поддержку MMU Virtualization (Intel EPT and AMD RVI) - это позволит уменьшить накладные расходы связанные с необходимостью поддержания согласованного представления памяти для нескольких vCPU.
- Выделяйте для виртуальной машины минимальное число vCPU. В случае с vCPU принцип чем больше чем лучше и быстрее - не работает. Выделение неиспользуемых ресурсов ведет к росту накладных расходов и снижению эффективности использования ресурсов. "Лишние" ресурсы выделенные виртуальной машине, не только могут не ускорить ее саму, но и привести к падению производительности виртуальных машин разделяющих с ней одни физические ресурсы. Планировщик гостевой ОС может выполнять миграцию однопоточной нагрузки между vCPU, что также снизит производительность.
- Отключите все неиспользуемые устройсва: COM, LPT порты, USB контроллеры, Floppy, CD, DVD устройства, сетевые карты, дисковые контроллеры. USB контроллеры потребляют ресурсы CPU, PCI - резервируют под себя ресурсы памяти - это общая рекомендация, не относящаяся только к ресурсам CPU.
- Чтобы использовать ресурсы несколько vCPU приложение должно поддерживать работу в многопоточном режиме.
После миграции из физического мира или создания новой виртуальной машины за ней стоит "присмотреть". Конечно если это не типовый сервис, для которого у Вас уже есть собственный бест-практис.
Не стоит полность, без оглядки доверять и выполнять требования (по выделению ресурсов) производителей прикладного ПО. Зачастую эти требования сильно завышены.
Счетчики которые стоит отслеживать для оптимизации производительности или первичного выявления проблем с производительностью. Названия счетчиков приведены в виде представленном в esxtop.
%RDY>10 - виртуальной машине не хватает ресурсов процессора, выстроилась очередь к ресурсам процессора. Вариантов может быть несколько: ресурсов действительно физического процессора действительно не хватает, ресурсов физического сервера хватает, но гипервизор не дает их виртуальной машине (машине надо русурсы 2-х Core, а у нее только 1 vCPU), использование Limit для данной машины. Узнать точную причину такого поведения можно используя другие счетчики:
%CSTP>3 - накладные расходы на многопроцессорную машину. Машина ждет освобождения нескольких vCPU для одновременного исполнения операций. Необходимо уменьшить число vCPU.
%MLMTD>0 - машина уперлась в Limit. Естественно, необходимо убрать ограничения по CPU.
%SWPWT>5 - машина ожидает чтения из файла подкачки. Необходимо увеличить выделенную память.
%VMWAIT - высокие значения этого параметра, говорят о проблемах с производительсностью других ресурсов: нехваткой памяти, медленной работой CXД и т.п.
В общем, все что сможет для обеспечения максимальной производительности сделает CPU Scheduler ESXi, а все остальное в руках администраторов.
В качестве источника использовался Performance Best Practices, настоятельно рекомендованный к вдумчивому прочтению.
Комментариев нет:
Отправить комментарий