Для лиги лени. Какая-то заумь про то, что не нужно, потому что все равно у нормальных людей все приложения давно в облаках на микросервисах, и прекрасно работают.
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Часть 2. Что из этого следует, и как устроен планировщик в Broadcom ESXi. Тут не будет ничего нового для тех, кто открывал документацию про изменение модели планировщика side-channel aware scheduler (SCA) - SCAv2, добавив Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors и Optimizing Networking and Security Performance Using VMware vSphere and NVIDIA BlueField DPU with BWI
Еще в 2017 году вышла бесплатная книга VMware vSphere 6.5 Host Resources Deep Dive, в которой тема достаточно раскрыта, и повторять ее нет смысла. Книга не на русском, еще раз: бесплатная, скачать можно тут.
Более короткий вариант, буквально на 3 страницы базовых терминов и состояний, описан в статье Understanding ESXi CPU scheduling из 2019 года.
В 2018 году вышла ESXi 6.7 (8169922), кстати, не забудьте поставить на нее, и всю линейку от 5.5 до 8.0.2, свежайший патч, а то получите по USB, на которую сейчас , в результате существования уязвимостей на уровне процессора (Spectre, Meltdown, L1TF, MDS) пришлось прикрутить целых три варианта планировщика:
по умолчанию
Side-Channel Aware Scheduler v1 (SCAv1) – безопасный, но «чуть тормозит».
В 6.7 U2 добавили Side-Channel Aware Scheduler v2 (SCAv2) – менее безопасный, почти не тормозит.
Есть статья из 2019 года «что когда выбирать» - Which vSphere CPU Scheduler to Choose и существовал онлайн помошник - vSphere 6.7 CPU Scheduler Advisor (спрятали куда-то).
Есть статья Performance of vSphere 6.7 Scheduling Options
В которой объясняются отличия планировщиков:
Перевод
Исправления, предоставленные ESXi, включали планировщик с учетом побочных каналов (SCAv1), который снижает количество векторов атаки конкурирующих контекстов для L1TF. Если этот режим включен, планировщик будет размещать процессы только на одном потоке для каждого ядра. Этот режим влияет на производительность главным образом с точки зрения объема (максимального числа vCPU), поскольку система больше не может использовать оба HT (потока) на ядре. Сервер, который уже был полностью загружен и работал на максимальной мощность снизит мощность примерно на 30%. Сервер, работавший на 75% мощности получит гораздо меньшее падение производительности, но загрузка CPU возрастет.
В vSphere 6.7 U2 планировщик с поддержкой побочных каналов был расширен (SCAv2) благодаря новой политике, позволяющей использовать HT, если оба (HT) потока выполняют контексты виртуального CPU из одной и той же виртуальной машины. Дополнительные каналы L1TF* ограничены, чтобы не раскрывать информацию между VM/VM или VM/гипервизор.
* L1TF - Resources and Response to Side Channel L1 Terminal Fault, смотреть график в абзаце For a specific subset of environments where it cannot be guaranteed that all virtualized guest operating systems are trusted.
(третий абзац не переведен)
Оригинал
The ESXi-provided patches included a Side-Channel Aware Scheduler (SCAv1) that mitigates the concurrent-context attack vector for L1TF. Once this mode is enabled, the scheduler will only schedule processes on one thread for each core. This mode impacts performance mostly from a capacity standpoint because the system is no longer able to use both hyper-threads on a core. A server that was already fully utilized and running at maximum capacity would see a decrease in capacity of up to approximately 30%. A server that was running at 75% of capacity would see a much smaller impact to performance, but CPU use would rise.
In vSphere 6.7 U2, the side-channel aware scheduler has been enhanced (SCAv2) with a new policy to allow hyper-threads to be utilized concurrently if both threads are running vCPU contexts from the same VM. In this way, L1TF side channels are constrained to not expose information across VM/VM or VM/hypervisor boundaries
To further illustrate how SCAv1 and SCAv2 work, the diagrams below show generally how different schedulers might schedule vCPUs from VMs on the same core. When there is only one VM in the picture (figure 1), the default placement, SCAv1 and SCAv2 will assign one vCPU on each core. When there are two VMs in the picture (figure 2), the default scheduler might schedule vCPUs from two different VMs on the same core, but SCAv1 and SCAv2 will ensure that only the vCPUs from the same VM will be scheduled on the same core. In the case of SCAv1, only one thread is used. In the case of SCAv2, both threads are used, but this always occurs with the vCPUs from the same VM running on a single core.
Дальше в статье идут графики, как разные планировщики влияют на производительность разных типов VM. До 30% потерь (остается 70%), что очень так неплохо.
Что еще надо знать про планировщик в ESXi
Планировщик оперирует «мирами» - world, при этом существуют отдельные «миры» для vcpu (vmx-vcpu), vmx-svga, kvm (vmx-ms), сети и процессов самой системы.
Прочитать про это можно, начиная (кроме вышепомянутого Deep dive) в статье vSphere 6.7 U2 & later CPU Scheduler modes: Default, SCA v1 and SCA v2
Каждые 2-30 миллисекунд (1/1000 секунды) планировщик проверяет нагрузку на физических ядрах, и выдает таймслот (слайс) для исполнения vCPU > pCPU. Можно понырять в NUMA, тогда станет еще сложнее понять, что там снизу на физике.
Затем в планировщик добавляются приоритеты исполнения, кому давать больше процессора (и памяти), описанные в разделе Resource Allocation Reservation.
При этом ресурсы считаются не по гигагерцам, а по shares, в зависимости от приоритета.
И есть, как сказано в первой части, отдельная настройка - Latency Sensitivity со следующими ограничениями:
Оригинал, тут все понятно и без перевода
You can turn on latency sensitivity for each VM at the VM level or at the host level.
This feature:
Gives exclusive access to physical resources to avoid resource contention due to sharing
With exclusive physical CPU (pCPU) access given, each vCPU entirely owns a specific pCPU; no other vCPUs and threads (including VMkernel I/O threads) are allowed to run on it. This achieves nearly zero ready time and no interruption from other VMkernel threads, improving response time and jitter under CPU contention.
Bypasses virtualization layers to eliminate the overhead of extra processing
Once exclusive access to pCPUs is obtained, the feature allows the vCPUs to bypass the VMkernel’s CPU scheduling layer and directly halt in the virtual machine monitor (VMM), since there are no other contexts that need to be scheduled. That way, the cost of running the CPU scheduler code and the cost of switching between the VMkernel and VMM are avoided, leading to much faster vCPU halt/wake-up operations.
Tunes virtualization layers to reduce the overhead
When the VMXNET3 paravirtualized device is used for VNICs in the VM, VNIC interrupt coalescing and LRO support for the VNICs are automatically disabled to reduce response time and jitter.
Although these and other features are disabled automatically when setting latency sensitivity to high, we recommend disabling each of these features independently to avoid any cascading effects when a single parameter is altered when tuning your virtual machines.
По этой (Latency Sensitivity) теме можно почитать следующее:
Shares explanation
Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5 (очень старый, но все еще полезный текст)
vSphere Resource Management Update 2 14 AUG 2020 VMware vSphere 6.7
vSphere Resource Management Update 3 VMware vSphere 7.0
vCenter Server and Host Management Update 3 Modified on 08 JAN 2024 VMware vSphere 7.0
Надо заметить, что еще в конце 2022 вышла ESXi 8.0 GA – это даже официально Public beta, согласно New Release Model for vSphere 8, что и показано в списке закрытых багов для ESXi 8.0 Update 2 (Этот абзац посвящен The одному моему знакомому. Покойному), а документацию обновляют для 7.
Кроме прочего, на скорость работы влияет включение \ выключение CPU Hot add , подробнейше описанное в 2017 - Virtual Machine vCPU and vNUMA Rightsizing – Guidelines,
раздел Impact of CPU Hot Add on NUMA scheduling и в статье CPU Hot Add Performance in vSphere 6.7
Перевод с дополнениями из 2019: Почему CPU Hot Add выключено по умолчанию в VMware vSphere, и как это влияет на производительность?
Можно VM прибить гвоздями прямо к ядру - Assign a Virtual Machine to a Specific Processor
Что все это значит «в целом»
Производительность виртуализации в ESXi by Broadcom зависит от десятков факторов, из которых основными являются:
Правильные настройки энергосбережения в BIOS и самой ESXi - Host Power Management Policies in ESXi
Установка актуальных обновлений для BIOS / CPU и правильный выбор планировщика
Установка актуальных обновлений для ESXi by Broadcom
Выключение CPU \ RAM hot add, если зачем-то включили
Уменьшение (да, именно уменьшение) числа vCPU до «сколько нужно», а не установка «сколько попросили». Больше в данном случае – НЕ значит лучше.
Наблюдение за esxtop раз, два Using esxtop to identify storage performance issues for ESX / ESXi (multiple versions) (1008205) три четыре пять шесть
И поискать ролик (куда то спрятали) с 60 Minutes of Non-Uniform Memory Architecture [HBI2278BE] by Frank Denneman из 2019 года
На сладкое – заныривать в NUMA - The 2016 NUMA Deep Dive Series от все того же автора: Frank Denneman
Part 0: Introduction NUMA Deep Dive Series
Part 1: From UMA to NUMA
Part 2: System Architecture
Part 3: Cache Coherency
Part 4: Local Memory Optimization
Part 5: ESXi VMkernel NUMA Constructs
Part 6: NUMA Initial Placement and Load Balancing Operations (не опубликована)
Part 7: From NUMA to UMA (не опубликована)
Итого
Виртуализация без настроек оптимизации, из коробки по умолчанию, безусловно, тормозит, по сравнению с чистым bare metal, на котором запущена 1 (одна) программа, которая использует 100% CPU и 100% RAM, и ничего не пишет на диски, и не читает с них. Потому что если программа пишет, и особенно читает, то тут будет иметь значение еще и настройка локальной и удаленной дисковых подсистем, буферов и режимов коммутации всех устройств по пути, скорости работы Ethernet – особенно если по пути вкручен DCB, и локально прикручены TSO и прочая.
Однако, использовать современный сервер, даже простейший ARM на 32 ядра, для 1-2 задач, которые еще и, в силу фундамента из костылей (1с), тормозят на любом устройстве и не способны использовать все 32 ядра – несколько экономически нецелесообразно. Хотя и возможно, это выбор бизнеса, что покупать и как применять. У одних моих коллег сервера использовались для оптимизации воздушных потоков в стойке – потому что заглушки на стойку надо покупать через конкурс, сервера в стойке уже есть, а вывоз сервера из ЦОД - мероприятие на половину дня, потому что для этого нужно присутствие материально ответственного лица. Поэтому сервера работали заглушкой. Очень помогало, кстати, против подсоса горячего воздуха с тыла стойки на фронт.
Для того, чтобы перейти от внутреннего ощущения «торможения» к каким-то цифрам, есть esxtop, есть cpu ready и десяток иных счетчиков. Есть статья Determining if multiple virtual CPUs are causing performance issues (1005362), вместе с всяким co stop (Maximizing VMware Performance and CPU Utilization) и iowait (Using esxtop to identify storage performance issues for ESX / ESXi (multiple versions) (1008205). Может, и правда «тормозит». Но, скорее всего, надо идти внутрь VM и смотреть на работающее внутри приложение – чего ему, хороняке, на самом деле надо.
ОДНОЗНАЧНОГО ОТВЕТА, КАК ИМЕННО ТОРМОЗИТ У ВАС И ПОЧЕМУ ТОРМОЗИТ – НЕТ.
Точнее, ответ есть, но он вам не понравится.
Бонус
Performance Best Practices for VMware vSphere 8.0 Update 2
Performance Best Practices for VMware vSphere 8.0 Update 1
При этом Best Practices for vSAN Networking существует пока только для 7.
How ESXi NUMA Scheduling Works
VMware NUMA Optimization Algorithms and Settings
Intermittent CPU ready time due to NUMA action affinity on VMware ESXi (начиная с части про LocalityWeightActionAffinity)
NUMA nodes are heavily load imbalanced causing high contention for some virtual machines (2097369)
И еще, если вы вдруг решили что все поняли, то можно нырнуть в реддит, или в статью Setting the number of cores per CPU in a virtual machine (1010184) и в уже ранее упомянутую статью Virtual Machine vCPU and vNUMA Rightsizing – Guidelines - в которой не только про NUMA, но и начинают идти уже глубже, в саму виртуальную машину и то, как программа внутри VM работает с памятью - Soft-NUMA (SQL Server).