Почему виртуализация снижает производительность ОС: причины и диагностика

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

Аппаратная виртуализация Intel VT-x, AMD-V, EPT, NPT и RVI заметно уменьшает накладные расходы, однако не отменяет конкуренцию за ресурсы. На результат влияют размер и топология vCPU, CPU overcommit, NUMA, memory ballooning, swap, тип виртуального контроллера, storage-драйверы, параметры виртуального диска, vSwitch и физическое хранилище.

Сам факт запуска ОС в VM редко объясняет резкую деградацию. При корректной конфигурации вычислительная нагрузка часто теряет небольшую долю производительности, а основные задержки появляются из-за нехватки физических ресурсов, неправильного размещения ВМ, медленного storage или неподходящих паравиртуальных драйверов. Причину нужно подтверждать метриками: latency, throughput, IOPS, время выполнения операции, CPU utilization, CPU ready, steal time, iowait, swap и сетевыми ошибками.

Почему производительность ОС в виртуализации ниже

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

Какие уровни добавляются между гостевой ОС и оборудованием

Типичная цепочка для дисковой операции выглядит так: приложение формирует запрос, файловая система гостя передает его виртуальному storage-драйверу, виртуальный контроллер принимает запрос, гипервизор ставит его в очередь, а storage stack отправляет данные на физический SSD, RAID-массив, ZFS-пул или NAS.

Для сети путь похожий. Пакет проходит через сетевой стек гостя, драйвер виртуального сетевого адаптера, vSwitch или bridge, физический uplink и внешний коммутатор. На каждом участке могут появиться очередь, дополнительная обработка, потеря пакетов или ограничение пропускной способности.

• Виртуальный CPU получает время выполнения через планировщик гипервизора. vCPU не закреплен за физическим ядром автоматически.
• Виртуальная память сопоставляет адреса гостя с физическими страницами хоста. EPT, NPT и RVI ускоряют это преобразование, но при дефиците RAM гипервизор может начать reclaim или ballooning.
• Виртуальный диск работает через файл, логический том, zvol, LVM или сетевое хранилище. Формат диска и режим размещения влияют на latency и IOPS.
• Виртуальный сетевой адаптер может эмулировать физическое устройство или использовать паравиртуальный драйвер VirtIO-net, VMXNET3 либо другой вариант конкретной платформы.
• Гипервизор синхронизирует доступ нескольких ВМ к общему CPU, RAM, storage и сети.

Аппаратная виртуализация снижает стоимость переходов между гостем и хостом. Она не устраняет задержки, связанные с очередями, блокировками, фрагментацией, NUMA и перегрузкой физических устройств. Поэтому две одинаковые ВМ с одинаковым объемом RAM могут показывать разное время отклика, если они размещены на разных datastore, NUMA nodes или хостах с разной соседней нагрузкой.

При переносе автоматизированной системы полезно разделять задержку приложения и задержку инфраструктуры. Практическая схема проверки CPU, cgroups, памяти, дискового I/O и overlay-сети собрана в статье о производительности автоматических систем на ВМ и в контейнерах.

Нормальные накладные расходы и реальные узкие места

Накладные расходы зависят от типа нагрузки и настроек. Последовательное вычисление с небольшим количеством системных вызовов обычно чувствительно к CPU frequency, планировщику и NUMA. База данных с большим числом синхронных записей сильнее реагирует на latency storage. Сетевой сервис может упереться в packet processing или очереди vSwitch даже при свободном CPU внутри гостя.

Высокая средняя загрузка CPU внутри ВМ не доказывает проблему гипервизора. Низкая загрузка тоже не доказывает наличие свободной вычислительной мощности. ВМ может проводить значительную часть времени в очереди хоста, а гостевая ОС будет показывать умеренный utilization. Для такой ситуации нужны CPU ready на стороне гипервизора и steal time в Linux.

Признаки реального узкого места обычно повторяются:

• растет время отклика при появлении соседней нагрузки;
• latency скачет сильнее, чем throughput;
• в гостевой ОС видны iowait, swap или steal time;
• на хосте растут очереди CPU, storage или сетевые drops;
• перенос ВМ на другой хост или datastore меняет результат без изменений приложения.

Сначала зафиксируйте baseline. Запишите версию гипервизора и guest tools, количество vCPU и RAM, тип виртуального контроллера, datastore, размер тестовых данных, число потоков и режим кэширования. Изменение нескольких параметров одновременно не позволяет установить причину.

Как гипервизор распределяет CPU между виртуальными машинами

Гипервизор планирует выполнение vCPU на доступных физических потоках. Когда несколько ВМ одновременно готовы выполнять инструкции, возникает очередь. При overcommit суммарное число vCPU выше числа физических потоков, поэтому каждая ВМ получает процессорное время согласно приоритетам, лимитам, резервам и текущей нагрузке.

vCPU не равен физическому ядру

vCPU представляет виртуальный поток выполнения, а не гарантированное физическое ядро. ВМ с 8 vCPU не получает восемь выделенных ядер, если администратор отдельно не настроил резервирование, affinity или CPU pinning. При спокойной нагрузке разница может быть незаметна. При одновременной компиляции, кодировании или запуске нескольких потоков очереди становятся видимыми по latency.

Избыточное количество vCPU иногда замедляет ВМ. Гипервизору приходится планировать больше виртуальных потоков, гостевая ОС увеличивает число runnable tasks, а параллельная задача может ждать доступный набор CPU. Для приложения, которому стабильно хватает 2-4 vCPU, конфигурация с 16 vCPU способна ухудшить время отклика при высокой загрузке хоста.

Проверяйте не только процент загрузки, но и:

• run queue и load average внутри Linux;
• число готовых к выполнению потоков;
• частоту CPU и признаки throttling;
• время выполнения одного потока и параллельного теста;
• распределение vCPU по физическим сокетам и NUMA nodes.

CPU overcommit, CPU ready и steal time

CPU ready показывает время, когда ВМ готова выполнять работу, но ожидает физический CPU. Высокое значение при умеренной загрузке гостя указывает на конкуренцию за вычислительные ресурсы. Точная шкала зависит от платформы: одни гипервизоры показывают миллисекунды, другие процент времени ожидания.

Steal time в Linux отражает время, которое виртуальный CPU хотел выполнять инструкции, но гипервизор отдал физический CPU другой задаче. Его можно увидеть через top, mpstat или sar. Если steal time растет одновременно с задержкой приложения, нужно изучить нагрузку хоста и соседние ВМ.

Для Windows сопоставляйте показатели Performance Monitor с метриками гипервизора. Полезны счетчики загрузки логических процессоров, времени выполнения процессов, длины очереди, прерываний и DPC. Показатель внутри гостя нужно проверять вместе с CPU ready или аналогичной метрикой хоста.

NUMA и привязка виртуальной машины к узлам памяти

В многосокетном сервере каждый NUMA node объединяет часть CPU и локальной RAM. Доступ к локальной памяти обычно предсказуемее, чем обращение к памяти другого узла. Когда ВМ помещается в один NUMA node, планировщику проще сохранить локальность. Большая ВМ может пересекать несколько узлов, и ее производительность начинает зависеть от размещения vCPU и страниц памяти.

Проблемы появляются при миграции vCPU между узлами, неравномерном распределении страниц и неудачном CPU pinning. Pinning фиксирует vCPU на выбранных физических потоках, но одновременно уменьшает свободу планировщика. В динамическом кластере это может ухудшить балансировку, поэтому настройку применяют после измерений.

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

Для CPU-зависимой ВМ сравните три сценария: обычное размещение, размещение с учетом NUMA и размещение с pinning. Снимайте время однопоточного и многопоточного теста, CPU ready, steal time и задержку приложения. Закрепляйте ресурсы только тогда, когда повторный тест показывает устойчивое улучшение.

Практические настройки BIOS/UEFI, VT-d, AMD-Vi, CPU pinning и PCIe passthrough разобраны в чек-листе настройки аппаратной виртуализации ВМ.

Как память ограничивает производительность гостевой ОС

Память, выделенная ВМ, не равна памяти, доступной приложению. Часть RAM занимает ядро гостя, драйверы, файловый кэш и фоновые процессы. На хосте эти страницы конкурируют с памятью других ВМ, кэшем гипервизора и служебными структурами.

Memory overcommit и ballooning

Memory overcommit позволяет назначить ВМ суммарно больше RAM, чем физически доступно хосту. Такой режим работает, пока ВМ используют память не одновременно или часть страниц удается освободить. При давлении гипервизор применяет reclaim, сжатие, ballooning или другие механизмы перераспределения.

Balloon-драйвер внутри гостя получает команду занять свободные страницы и вернуть их хосту. Для гипервизора это способ забрать RAM у ВМ, которая сейчас использует ее не полностью. Для гостя процесс выглядит как уменьшение доступной памяти. Файловый кэш сокращается, растет число обращений к диску, а приложение может получить более высокую latency.

Проверяйте показатели на двух уровнях:

• в госте, доступную RAM, reclaim, major page faults, swap in/out и скорость записи в кэш;
• на хосте, memory pressure, ballooning, compression, swapping и свободную RAM по NUMA nodes.

Свободная память хоста не всегда доступна конкретной ВМ в нужный момент. На многосокетной системе важны размер локального узла, политика размещения страниц и текущая нагрузка соседних ВМ.

Swap внутри ВМ и swap на хосте

Swap внутри гостя означает, что гостевая ОС вытесняет страницы на виртуальный диск. Если сам хост одновременно вытесняет страницы ВМ на собственный swap, формируется двойной путь записи. Задержка резко растет, поскольку операция проходит через storage stack гостя, виртуальный диск, гипервизор и физическое устройство.

Для Linux начните с команд:

free -h
vmstat 1
sar -W 1

В vmstat следите за колонками si и so, в sar -W за swap in/out. Важен не сам факт наличия настроенного swap, а активное вытеснение страниц во время проблемного теста. На Windows используйте Performance Monitor и сопоставляйте счетчики страниц, доступной памяти, hard faults и задержки диска.

Если swap активен, сначала проверьте рабочий набор приложения, лимиты RAM и память соседних ВМ. Увеличение vCPU не исправит нехватку памяти и часто добавит конкуренцию за CPU.

Распределение RAM с учетом NUMA

Размер ВМ нужно сопоставлять с емкостью NUMA node, числом vCPU и профилем приложения. База данных с большим кэшем чувствительна к локальности страниц, а небольшая служебная ВМ обычно переносит межузловой доступ без заметной деградации.

Проверяйте распределение RAM на хосте, наличие memory reservation и фактическое размещение страниц. KSM может объединять одинаковые страницы разных ВМ и экономить RAM, но поиск совпадений требует CPU. Для предсказуемых latency критичных систем резервирование памяти часто полезнее агрессивного overcommit.

Виртуальные диски и производительность системы

Дисковый I/O проходит через несколько очередей, поэтому средняя скорость накопителя не описывает реальный результат. На latency влияют файловая система гостя, виртуальный диск, контроллер, storage-драйвер, datastore, физический массив, сеть до NAS и фоновые операции.

Формат виртуального диска и способ размещения

Thin provisioning выделяет физическое место по мере записи. Это экономит пространство и ускоряет создание ВМ, но добавляет операции расширения и повышает риск заполнения пула. При заполнении datastore или ZFS-пула задержки могут вырасти для всех соседних машин.

Thick или preallocated-размещение заранее резервирует место. Такой режим упрощает контроль емкости и уменьшает часть операций расширения, однако не гарантирует низкую latency. Физический массив, контроллер и конкуренция ВМ все равно остаются ограничениями.

Снапшоты и цепочки copy-on-write увеличивают количество уровней, которые нужно проверить при чтении и записи. Длинная цепочка снапшотов усложняет storage stack, а фрагментация может ухудшить последовательный доступ. Перед нагрузочным тестом зафиксируйте число снапшотов, свободное место и состояние пула.

Для ZFS и NAS нельзя переносить настройки гостя на хранилище без проверки профиля. recordsize, режим sync, ARC, тип vdev, compression, deduplication, scrub и resilver по-разному влияют на последовательный I/O, случайные операции и синхронные записи. База данных и файловый сервер могут требовать разных настроек.

Виртуальный контроллер и паравиртуальный storage-драйвер

Эмулируемый IDE, SATA или устаревший SCSI-контроллер совместим с большим числом гостевых ОС, но требует от гипервизора больше работы на каждый запрос. Паравиртуальные варианты уменьшают путь обработки. В KVM и Proxmox часто используют VirtIO, в VMware для подходящих сценариев применяют VMware Paravirtual SCSI.

После смены контроллера убедитесь, что гостевая ОС имеет нужный драйвер. Windows может потерять доступ к системному диску при переключении на VirtIO без предварительной установки драйвера. После миграции проверьте версию guest tools, состояние устройства, ошибки драйвера и negotiated параметры очередей.

Диагностируйте storage по уровням:

1. Проверьте файловую систему гостя и ее ошибки.
2. Измерьте latency виртуального диска и длину очереди.
3. Посмотрите метрики datastore, пула, RAID или zvol.
4. Проверьте сеть, если storage находится на NAS.
5. Сопоставьте результат с нагрузкой соседних ВМ и фоновыми задачами.

Почему средние IOPS не объясняют медленную работу

IOPS без профиля нагрузки малоинформативны. Последовательное чтение крупными блоками создает одну картину, случайная запись малыми блоками, другую. Синхронный fsync ждет подтверждения сохранения данных, поэтому для журнала базы данных важнее latency одной записи, чем максимальный throughput.

Очередь запросов помогает накопителю повысить throughput, но при чрезмерной глубине очереди растет время ожидания. Измеряйте минимум четыре параметра: IOPS, throughput, среднюю latency и перцентили p95/p99. Последние показывают редкие задержки, которые часто определяют время ответа приложения.

Тестируйте профиль, похожий на рабочий. Пример для временной тестовой области:

fio --name=vm-test --filename=/path/testfile --size=4G --rw=randrw --rwmixread=70 --bs=8k --iodepth=16 --direct=1 --runtime=60 --time_based

Команда требует корректно выбранного тестового пути. Запуск по системному диску или рабочей базе может повредить данные и изменить кэширование. Тестовые файлы удаляйте после измерения.

Как отличить проблему гостевого диска от проблемы storage

В госте высокий iowait говорит о времени ожидания I/O, но не показывает источник задержки. Сопоставьте его с await, utilization и queue size в iostat. Если latency растет только внутри одной ВМ, ищите драйвер, файловую систему, лимит или снапшот. Если одновременно замедляются несколько ВМ, проверяйте datastore и физический массив.

iostat -xz 1
vmstat 1
sar -d 1

На ZFS-пуле проверьте заполнение, состояние vdev, активные scrub и resilver, нагрузку ARC, синхронные записи и наличие дедупликации. Для RAID изучите состояние массива, очередь контроллера и фоновые операции. Для NAS добавьте проверку сетевого RTT, retransmits и пропускной способности.

Команды и безопасный порядок поиска узкого места в дисках, RAID и файловых системах собраны в руководстве по производительности серверного хранилища.

Сетевые драйверы и виртуальный коммутатор

Сетевая производительность ВМ зависит от типа виртуального адаптера, гостевого драйвера, очередей, offload, vSwitch или bridge, VLAN, MTU и физического uplink. Один тест скорости не показывает, на каком участке возникло ограничение.

Эмулируемый адаптер и паравиртуальный NIC

Эмулируемый адаптер совместим с гостевыми ОС, но его обработка обычно дороже для CPU. Паравиртуальные адаптеры VirtIO-net и VMXNET3 передают пакеты эффективнее и поддерживают функции, рассчитанные на виртуальную среду.

Проверьте внутри Linux имя интерфейса, состояние линка, ошибки, drops, скорость и offload:

ip -s link
ethtool eth0
ethtool -k eth0
ethtool -S eth0

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

vSwitch, bridge, VLAN и MTU

Пакет может задерживаться в очередях виртуального коммутатора, на bridge или физическом uplink. Ошибочный VLAN tagging приводит к потере связности или нестабильной передаче. Несогласованный MTU вызывает фрагментацию, drops или проблемы только для крупных пакетов.

Jumbo frames полезны только при одинаковом MTU на госте, vSwitch, физическом интерфейсе и коммутаторе. Изменение MTU на одном уровне без проверки всей цепочки создает трудноуловимые ошибки. Снимайте counters на гостевом интерфейсе, хосте и физическом коммутаторе.

Проверьте количество очередей виртуального NIC, распределение прерываний, offload и загрузку физического uplink. Увеличение числа очередей помогает многопоточной сетевой обработке, но повышает потребление CPU. Настройка должна соответствовать числу vCPU и реальному числу пакетов в секунду.

Как тестировать сеть без ложных выводов

iperf3 позволяет разделить проверку throughput и задержки. Запускайте сервер на одной машине, клиент на другой и фиксируйте направление теста, число потоков, MTU и длительность.

iperf3 -s
iperf3 -c SERVER_IP -t 60 -P 1
iperf3 -c SERVER_IP -t 60 -P 8
iperf3 -c SERVER_IP -t 60 -P 8 -R

Один поток показывает поведение приложения с последовательной передачей. Несколько потоков помогают обнаружить ограничение одного CPU, очереди и распределение прерываний. Режим -R меняет направление передачи и помогает найти асимметрию.

Параллельно фиксируйте RTT, packet loss, retransmits, drops и CPU utilization. Низкая скорость при высоком retransmit указывает на потери или ошибки канала. Низкая скорость при чистом канале и загрузке одного vCPU требует проверки сетевого драйвера, offload и обработки пакетов.

Как ОС ведет себя под разными типами нагрузки

Одна ВМ может быстро компилировать код и медленно обслуживать базу данных. Причина в разных профилях нагрузки. Для диагностики нужно связать симптом с ресурсом, метрикой и повторяемым тестом.

CPU-bound: компиляция, кодирование и вычисления

CPU-bound задача постоянно готова к выполнению и быстро показывает конкуренцию за физические ядра. Если внутри гостя utilization близок к 100%, проверьте, получает ли ВМ нужное процессорное время. Высокий steal time или CPU ready укажет на задержку планирования, а высокая частота runnable tasks при низком steal может означать слишком большое число потоков приложения.

Сравнивайте один поток и несколько потоков. Однопоточный тест помогает проверить частоту CPU и миграцию vCPU. Многопоточный тест выявляет overcommit, co-stop, NUMA locality и ограничения очередей. Для точного анализа профиля CPU используйте perf в Linux, а результаты сопоставляйте с метриками хоста.

Disk-bound: базы данных, логи и виртуальные диски

Высокий iowait означает ожидание завершения дисковых операций, но не объясняет их причину. Для базы данных измеряйте fsync latency и случайную запись малыми блоками. Для файлового сервера отдельно проверяйте последовательное чтение, запись и число параллельных клиентов.

Сопоставьте await в госте с latency datastore. Если гостевая ОС показывает большое ожидание, а физический storage свободен, ищите контроллер, драйвер, лимит IOPS или очередь виртуального диска. Если задержка растет на всех ВМ, проверьте RAID, ZFS, NAS и фоновые операции.

Network-bound: сервисы, репликация и загрузка данных

Сетевой сервис может упираться в полосу, RTT или стоимость обработки пакетов. Репликация часто чувствительна к стабильности задержки и retransmits, а массовая загрузка данных сильнее зависит от throughput.

Проверьте тест в обоих направлениях и с разным числом потоков. Если один поток медленный, а несколько потоков достигают расчетной скорости, ищите ограничение очереди или одного vCPU. Если все варианты показывают drops, проверьте MTU, VLAN, физический uplink и counters vSwitch.

Memory-bound: кэширование, базы данных и высокие рабочие наборы

При нехватке RAM приложение теряет файловый или внутренний кэш. Число обращений к диску растет, latency становится неровной, а guest OS может начать использовать swap. На хосте аналогичный эффект создают ballooning, reclaim и memory overcommit.

Проверяйте major page faults и swap in/out во время конкретной операции. Если на хосте свободна RAM, но внутри ВМ доступная память мала, изучите ballooning, reservation, NUMA locality и лимит памяти. Увеличение RAM оправдано после подтверждения роста рабочего набора, а не по одному показателю свободной памяти.

Пошаговая диагностика производительности ВМ

Диагностика должна двигаться от наблюдаемого симптома к проверяемой гипотезе. Случайное увеличение vCPU или RAM меняет условия теста и иногда усиливает конкуренцию.

Шаг 1. Зафиксировать симптом и baseline

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

Baseline должен быть воспроизводимым. Используйте одинаковые версии ОС и драйверов, один размер тестовых данных, одинаковое число потоков, глубину очереди и режим кэширования. Запишите состояние снапшотов, thin provisioning, фоновых backup, scrub, resilver и репликации.

Для сравнения физического сервера и ВМ применяйте одинаковый профиль нагрузки. Сравнение максимальной скорости физического SSD с latency базы данных внутри ВМ не дает полезного вывода.

Шаг 2. Проверить гостевую ОС

В Linux начните с общего состояния CPU, памяти, дисков и сети:

uptime
vmstat 1
iostat -xz 1
sar -n DEV 1
ss -s

uptime и load average показывают очередь задач, vmstat помогает увидеть runnable tasks, swap и iowait, iostat показывает latency и очереди дисков, sar -n DEV помогает найти сетевые ошибки, а ss -s показывает состояние сокетов.

Проверьте steal time через top, mpstat -P ALL 1 или sar -u 1. Состояние виртуальных устройств и guest tools изучайте в логах ядра и менеджере устройств. Ошибки reset, timeout, link flap и смена имени сетевого интерфейса после миграции требуют отдельной проверки драйверов.

Для Windows используйте Performance Monitor. Сопоставляйте Processor\% Processor Time, System\Processor Queue Length, Memory\Available MBytes, Memory\Pages\sec, LogicalDisk\Avg. Disk sec/Read, LogicalDisk\Avg. Disk sec/Write, Network Interface\Bytes Total/sec и счетчики ошибок. Названия счетчиков могут отличаться между версиями Windows и языками системы.

Проверяйте нагрузку приложения отдельно. Общая загрузка ВМ может выглядеть нормальной, когда один процесс упирается в CPU, блокировку, один диск или одно сетевое соединение.

Шаг 3. Проверить хост и соседние ВМ

На хосте изучите CPU ready или эквивалент, steal, co-stop, распределение vCPU, memory pressure, ballooning и swapping. Для storage нужны latency, queue depth, IOPS и throughput по datastore, пулу или физическому массиву. Для сети проверьте drops, ошибки, очереди vSwitch и загрузку uplink.

Составьте карту конкуренции. Запишите, какие ВМ используют тот же datastore, NUMA node, физический uplink и пул CPU. Отдельно ищите backup, snapshot consolidation, scrub, resilver, репликацию, дедупликацию и другие фоновые операции.

Проверьте лимиты, shares, reservations и affinity. Лимит CPU способен замедлять ВМ даже при свободном хосте. Резервация памяти снижает риск вытеснения, но уменьшает ресурсный пул для других машин. Настройка должна соответствовать критичности сервиса и характеру нагрузки.

При сложной топологии полезно сверить рекомендации с пошаговым алгоритмом диагностики производительности системы. Он помогает сохранить порядок проверки CPU, памяти, swap, дисков, очередей и сети.

Шаг 4. Повторить тест после изоляции ресурса

Изолируйте одну переменную. Перенесите ВМ на другой хост или datastore, временно остановите фоновые операции, уменьшите нагрузку соседей, снимите снапшоты или проверьте другой виртуальный контроллер. Затем повторите тот же baseline-тест.

Гипотеза подтверждена, если изменение ресурса предсказуемо меняет результат и метрики. Например, перенос на свободный datastore снижает p99 latency одновременно с очередью storage. Если результат не меняется, верните настройку и проверьте следующий уровень.

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

Как повысить производительность виртуальной машины

Настройка должна следовать подтвержденному узкому месту. Сначала исправьте конкуренцию и драйверы, затем подберите размер ресурсов, после этого повторите baseline.

Настройка CPU и NUMA

• Выделяйте столько vCPU, сколько требует реальная нагрузка. Начните с меньшего числа и увеличивайте его по метрикам.
• Проверяйте CPU ready, steal time, run queue, частоту и throttling.
• Снижайте CPU overcommit на перегруженном хосте.
• Сопоставляйте размер ВМ с NUMA node и проверяйте vNUMA для крупных машин.
• Применяйте reservation, affinity, CPU pinning и hugepages для предсказуемых критичных нагрузок после тестирования.

CPU pinning не подходит как универсальный способ ускорения. В динамическом кластере он может ухудшить балансировку и усложнить live migration. Для обычных сервисов сначала проверьте размер vCPU и конкуренцию на хосте.

Настройка памяти

• Согласуйте RAM ВМ с рабочим набором приложения, файловым кэшем и запасом для ядра гостя.
• Проверьте ballooning, memory overcommit, reclaim и swap на двух уровнях.
• Зарезервируйте память для критичной ВМ, если хост регулярно испытывает memory pressure.
• Распределяйте RAM с учетом NUMA locality и размера физических узлов.
• После изменения сравните available RAM, major page faults, swap in/out и latency приложения.

Свободная RAM на хосте не отменяет лимит ВМ, ballooning или неудачное размещение страниц. Решение принимайте по периоду проблемной нагрузки, а не по единичному снимку мониторинга.

Настройка виртуальных дисков и storage

• Выбирайте паравиртуальный контроллер, совместимый с гипервизором и гостевой ОС.
• Проверяйте установку и версию VirtIO, VMware Paravirtual SCSI или другого подходящего storage-драйвера.
• Контролируйте thin provisioning, свободное место, фрагментацию и цепочки снапшотов.
• Для базы данных измеряйте sync write, fsync latency и случайный I/O.
• Для файлового сервера отдельно тестируйте последовательный throughput и параллельные операции.
• На ZFS и NAS учитывайте recordsize, sync, ARC, тип vdev, scrub, resilver и сетевой путь.

Не ориентируйтесь на одну цифру IOPS. Сравнивайте latency, p95/p99, throughput, queue depth и профиль запросов. Перед изменением кэшей и режима записи проверьте требования к сохранности данных.

Настройка виртуальной сети

• Используйте подходящий паравиртуальный NIC, VirtIO-net или VMXNET3, если это поддерживает выбранная платформа.
• Проверьте гостевой драйвер, offload, число очередей и распределение прерываний.
• Сверьте MTU на госте, vSwitch или bridge, физическом uplink и коммутаторе.
• Проверьте VLAN tagging, packet drops, retransmits и ошибки интерфейса.
• Сравните один поток, несколько потоков и обратное направление через iperf3.

Для отдельного сравнительного стенда можно использовать VDS с предсказуемым набором ресурсов, например инфраструктуру Timeweb Cloud. Такой стенд не заменяет тест на рабочем гипервизоре, но помогает отделить ограничения приложения от перегруженного локального хоста.

Контрольный тест после оптимизации

Повторите baseline при сопоставимой нагрузке. Сравните время выполнения, latency, throughput, IOPS, CPU ready, steal time, swap, iowait, packet drops и ошибки драйверов.

Изменение можно считать полезным, если оно улучшает нужный показатель без ухудшения соседних. Рост throughput при увеличении p99 latency не всегда подходит для базы данных. Снижение CPU utilization при появлении swap тоже не означает улучшение.

Зафиксируйте итоговую конфигурацию: число vCPU, RAM, NUMA-политику, reservation, тип контроллера, драйверы, datastore, снапшоты, сетевой адаптер, MTU и условия теста. Повторяемость результата важнее единичного максимального показателя.