Причин падения производительности виртуальных машин много, но основная часть жалоб связана с процессором, оперативной памятью, дисковой подсистемой или сетью. Поговорим, на какие метрики смотреть и каким инструментарием пользоваться.
Падение производительности виртуальных машин из-за проблем с CPU
Для диагностики CPU актуальны два основных показателя:
- CPU Used, который характеризует процент активно задействованных мощностей виртуальных CPU.
- CPU Ready, который обозначает время, когда машина была готова работать, но не запускалась на физическом процессоре по причине нехватки ресурсов.
Начинаем с CPU Used. Если он меньше 90%, среднее значение загруженности CPU в виртуальной машине не влияет на производительность. Если больше — скорей всего причина именно в нехватке vCPU или недостаточной производительности процессора сервера.
Показатель CPU Ready должен быть не больше 10% на каждое ядро процессора. Детализировать CPU Ready помогают счетчики Readiness и Ready. Readiness показывает данные по виртуальной машине (ВМ) за последний час с интервалом 20 секунд. Он актуален для диагностики причин падения производительности «здесь и сейчас». Ready отражает, сколько времени за период измерения ядро ВМ находилось в состоянии, когда не выполняет полезную работу. Метрика удобна для оценки падения ВМ в динамике, в контексте каких-то определенных процессов.
Для анализа производительности CPU, помимо счетчиков vCenter, можно использовать утилиту ESXTop и вкладку Performance Tab.
Когда проблема в оперативной памяти
Проблемы с оперативной памятью диагностировать проще. Смотрим на два базовых показателя — Ballooned и Swapped.
Когда объем оперативной памяти, изъятой у ВМ, больше, чем объем физической памяти, которую ВМ потребляет с хоста, это квалифицируется как balooning. Ничего критичного, но если показатели Balloon сильно выше объема физической памяти (Consumed), падение производительности ВМ неизбежно. Если проблема не в Ballooned, он должен быть равен 0.
Swapped показывает объем гостевой физической памяти, выгруженной в файл подкачки виртуальной машины. Машина, попавшая в своп, не просто теряет производительность, она намертво зависает. При отсутствии проблем с памятью, показатель Swapped должен быть нулевым.
Инструмент для мониторинга проблем с оперативной памятью можно использовать тот же, что и для CPU — ESXTop. Основными метриками будут SWCUR, как объем оперативной памяти из Swap-файла, и MCTLSZ, показывающий Balloon в мегабайтах.
А если причина в диске?
Один из самых показательных симптомов — регулярное превышение latency до 10-15 мс и более. Сам по себе показатель задержки времени отклика зависит от целого ряда факторов, начиная от времени прохождения сигнала по сети передачи данных и заканчивая задержкой внутри гипервизора. Первый определяется как DAVG. Чтобы понять, не здесь ли причина ухудшения производительности ВМ, имеет смысл посмотреть на счетчики производительности СХД.
Показатель задержки внутри гипервизора обозначается аббревиатурой KAVG и отображается во вкладке Perfomance в vSphere Client. В нормальных условиях KAVG должен быть как минимум значительно ниже DAVG, а лучше — до 1 мс.
Второй момент, на который стоит обратить внимание — IOPS. Этот показатель актуален для рандомных нагрузок. Например, при доступе к блокам, расположенным в разных местах диска. Такие нагрузки характерны для ERP и CRM, баз данных. Для проверки IOPS подходит утилита ESXTop: в категории дисковой подсистемы она покажет CMDS/s (общее число SCSI-команд) и IOPS как сумму READS/s и WRITES/s. В норме IOPS должно быть более-менее близко к показателю CMDS/s.
Если значение IOPS показательно при рандомных нагрузках, то пропускная способность важна при последовательных. Иногда падение производительности напрямую связано с большим размером блока. Какой блок является «слишком большим» для дисковой подсистемы, можно выяснить у производителя СХД или в ходе тестов на лабораторном стенде.
Какие проблемы могут быть с сетью?
Обычно до проверки сети дело не доходит, поскольку основные причины падения производительности кроются в проблемах дисковой подсистемы или процессора. Однако в случае с массированным потоком несжатых данных канал может забиваться полностью. Чтобы проверить сеть, в том же ESXTop нужно посмотреть DRPTX (процент отправленных потерянных пакетов) и DRPRX (процент утерянных входящих пакетов). Оба показателя должны быть нулевыми. Если нет — в сетевых устройствах или их настройках есть проблема, которая требует решения.
Мы рассмотрели опорные точки для поиска причин снижения производительности виртуальных машин. Обычно их более чем достаточно для базовой диагностики. Если же по метрикам все хорошо, а проблема остается — обратитесь в техподдержку. Копнем глубже, найдем и поможем исправить проблему.