Для лиги лени. Какая-то заумь про то, что не нужно, потому что все равно давно у нормальных людей все приложения в облаках на микросервисах, и прекрасно работают.
Часть 4. Что из этого следует, и как устроен планировщик в KVM или KVM- QEMU. Тут тоже не будет ничего нового, но будет масса ошибок.
Ранее:
Часть 1 Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 1: Общий обзор
Часть 2 Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 2: ESXi by Broadcom
Тормозящая виртуализация на x86. Небольшая попытка разобраться. Часть 3: Hyper-V
Архитектура KVM
Как сказано выше:
у ESXi сначала загружается ESXi, затем все остальное. Просто и легко. Желающие могут при загрузке нажать пару кнопок и наблюдать за загрузкой.
У MS Hyper-V сначала грузится корневой раздел виртуализации, уже внутри его загружается GUI, и затем стартуют остальные разделы.
У KVM – в целом что-то похожее. Вот картинка от AWS с kernel и хостовая ОС живет отдельно. RH вместо картинок размещает ролик про то, что RH это хорошо.
Парой абзацев ниже на AWS написана откровенная чушь -
Kernel-based Virtual Machine (KVM) and VMware ESXi both provide virtualization infrastructure to deploy type 1 hypervisors on the Linux kernel.
Почему чушь
ESXi давным давно, лет 15, НЕ linux kernel, читать про VMkernel тут. При этом vCenter использует Photon OS, которая все же Linux. Раньше (давно) vCenter на Windows был, потом решили сэкономить. ESX (без i) был давно-давно, последние следы Linux выкинули после судебного разбирательства про использование GPL вместе с изменением модели драйверов в версии 7 (выкинули vmklinux driver API) – о чем было известно с 2017 года.
KVM (наконец-то)
Общеизвестно, что KVM живет в связке с QEMU, и треды (или нити, как лучше сказать то?) распределяются через стандартный планировщик (раньше был O(1) scheduler, потом – с 2007 - Completely Fair Scheduler (CFS), про него даже на хабре была статья CFS vs O(1) scheduler.
В 2016 году вышел патч и статья «"The Linux Scheduler: A Decade of Wasted Cores"» - сохранилась тут или тут.
Работа по построению дерева задач описана в разделе CFS Scheduler.
Год назад вышел Earliest eligible virtual deadline first (EEVDF).
При этом что планировщик, что QEMU как-то странно дружат с распределением и по полноценным ядрам, и по HT узлам, и по NUMA нодам, поэтому у RH отведено две страницы в документации на тему «как смотреть что случилось, и какие ручки крутить» в разделе Identifying CPU and NUMA topology.
Про новый планировщик можно почитать тут и тут - Earliest Eligible Virtual Deadline First : A Flexible and Accurate Mechanism for Proportional Share Resource Allocation - Ion Stoica, Hussein Ab del-WahabDepartment of Computer Science, Old Dominion University Norfolk, Virginia, 23529-016
А дальше .. а дальше начинаются проблемы. Потому что статьи типа этой (Earliest Deadline First (EDF) CPU scheduling algorithm ) набиты отборным маркетингом:
Responsiveness: EDF provides a high level of responsiveness for time-critical tasks. It ensures that tasks are scheduled and executed promptly, reducing response times and improving system performance.
Predictability: EDF provides predictability in terms of task execution times and deadlines. The scheduling decisions are deterministic and can be analyzed and predicted in advance, which is crucial for real-time systems.
От статьи Scheduling: Earliest Deadline First не легче ни разу – потому что из статьи не понятно, как планировщик задачи на 10-20 ядер поведет себя, если часть задач из гостевой операционной системы выполнилась, а часть нет. 10-ms слоты упомянуты тут - Composing Scheduling Policies
Therefore, providing a CPU reservation of 5 ms / 33 ms, or 15% of the CPU, using EEVDF requires allocating 45% of the processor bandwidth when the EEVDF scheduler uses a 10 ms quantum. Clearly, this degree of over-reservation is not acceptable in general. EEVDF’s error bounds are optimal, so it is impossible for a different proportional share scheduler to do better than this. To reduce the level of pessimism, the only parameter available to adjust is the scheduler quantum size.
Но найти механизм отрезания Minroot – я не сразу смог. Его, надо сказать, просто так, от скуки, отрезать даже на Windows не нужно, можно внезапно узнать о том, что для обработки сетевого трафика больше чем просмотр Хабра – одного, даже 4 ГГц ядра – недостаточно. Между тем Linux Minroot есть, описан в статье KVM Real Time Guest Config , раздел Host partitioning plan
Остальное управление реализовано через virt-install и содержит достаточно богатый набор настроек в части CPU – cpuset, numatune и даже что-то вместо Enhanced vMotion Compatibility – ключ cpu. И на этом как бы все. Описание ключей тут
Дальше идет специфика – у кого есть cpuunits и affinity (proxmox и openvz), а у кого нет.
Какой-то методики тестирования, как я уже писал – нет, и быть не может как по административным причинам, так и по техническим – у всех свой набор задач и виртуальных машин, и кто как работает и кто кому мешает – сложно.
Мониторинг
Самое сложное в таких сравнениях, это определиться с мониторингом под нагрузкой. Если в ESXi есть достаточно подробно описанные esxtop, то в KVM получить срезы задержек по компонентам \ пути прохождения данных – сложно. Отладка случаев «что-то в драйвере подтекало и дисковая система стала тормозить» может быть очень интересной.
Хотя у RH есть документация на Monitoring Performance in Virtual Machine Manager
и на Virtual machine performance monitoring tools с использованием perf - perf kvm stat live
или взять какие-то шаблоны отсюда - Monitoring VMs on OpenStack (or KVM) using Graphite + Collectd (Last update: 2020-05-14T08:13:47 )
Все это обещает быть очень интересным в ближайшие пару месяцев, в связи со свежей уязвимостью - GhostRace CPU vulnerability threatens all major architectures — IBM and VU Amsterdam researchers detail new cross-platform speculative execution attack.
Комментарии (13)
Newbilius
17.03.2024 20:42Для лиги лени
Что-то локальное пикабушное. Почему бы не юзать более распространённое TL;DR?)
Tufed
17.03.2024 20:42+6Почему автор использует/употребляет не то, что привычно комментатору. Ох, аж флешбеки накатили. Как будто я снова читаю форумы с вопросами и ответы по линуксу в 00-х. Бррр..
orryon
17.03.2024 20:42+3столько всего написано в 4х частях. а почему просто не написать четко:
1) в современной компьютерной архитектуре в рамках виртуализации можно поделить/распределить между виртуалками ядра, DRAM, пространство на накопителях, но невозможно распределить ресурс контроллера DRAM - он один на сокет, а часто и на плату вся DRAM подключена к одному, а если и к нескольким - то ещё хуже, один процесс выборкой из памяти на какое-то время фактически занимает пару контроллеров (один читает из памяти, второй закидывает в кэш своего сокета).
фактически это означает что всего одно приложение, которое интенсивно работает с DRAM с данными, случайно раскиданными по области всего в несколько раз превышающей размер кэша CPU, практически урежет доступ к контроллеру DRAM все процессы как своей виртуалки, так и остальных. а что делать ? доступ к дискам этому приложению стоит ещё дороже.
2) время случайного доступа в память практически не изменилось с прошлого века и составляет 50-80ns (для серверной памяти больше). ситуацию немного облегчает рост числа каналов и банков, но в рамках виртуализации не все так здорово по ним раскладывается. к тому же в реальных приложениях нужны не абстрактные случайные адреса, а очень даже конкретные, которые все ещё фиг знает как раскиданы по физическим адресам.
3) регулярный сброс кэша CPU из-за всяческих уязвимостей. при этом более-менее быстрая загрузка в кэш из DRAM идет только в burst, а "доза" одного bursta - до сих пор всего 2KB. то есть время чтения максимальной порции в режиме burst почти сравнялось с временем установки случайного адреса чтения. что 4 (точнее 64) байта читать, что 2KB - разница уже менее чем вдвое (для памяти с эффективной частотой 3-5GHz)
4) в режиме виртуализации скорость работы с DRAM падает и без планировщиков и прочего. достаточно просто в винде включить/отключить виртуализацию и проверить скорость случайного доступа в aida64 чтобы увидеть как оно влияет, хотя никаких VM тут ещё даже нет.
насчет обмена с внешними устройствами - накопителями, сетями, и т.п., разработчики уже привыкли думать и оптимизировать. а вот насчет работы с памятью, сводя её по возможности к burst режиму, при этом фактически отказываясь от ООП, от строк и объектов по ссылкам в куче (неважно, управляемой или нет), то есть от динамического неупорядоченного размещения объектов в памяти, возвращаясь к массивам плоских структур, к сбору доменов строк, в которых предполагается поиск, в сплошной текст с параллельным массивом индексов начал/длин - нет. движуха в разработке все ещё идет наоборот, в обратную сторону.
Grigory_Otrepyev Автор
17.03.2024 20:42но невозможно распределить ресурс контроллера DRAM - он один на сокет, а часто и на плату вся DRAM подключена к одному, а если и к нескольким - то ещё хуже,
Потому что это так только на дешевых x86, про что было в первой части статьи. На IBM Power и не только - это не так.
4) в режиме виртуализации скорость работы с DRAM падает
Это тоже не так "в целом", только для x86 и то не всегда.
orryon
17.03.2024 20:42то есть где-то можно задать мультиплексирование контроллера DRAM между ВМ с выделением каждой определенного bandwidth ? где об этом можно прочесть ?
а скорость работы (точнее задания адреса для выборки строки в кэш) с DRAM падает по вполне определенным причинам - вклинивается ещё один слой косвенной адресации страниц. там где не падает - она изначально ниже.
сама то структура работы с DRAM от платформы не зависит - нужен физический адрес строки, по которому она переписывается из внутреннего массива в строку банка, не мгновенно, потом столбца, потом "можно читать".
скорее x86 имеет такой режим, где трансляция логического адреса, используемого в процессе, в физический происходит достаточно быстро, всего 2 уровня разыменования по большому счету. с виртуализацией на 1 больше.
StaceZ
17.03.2024 20:42+1А может, раз уж пошла такая пьянка, и если есть опыт, то и про IBM PowerVM напишите? Ну раз уж в первой статье были отзывы про p720. Меня как-то давно смущает отсутствие баре-метал как класса, хотя с отзывом про производительность я полностью согласен. Про виртуализацию на x86 я, в целом, тоже согласен, но за ссылки спасибо ;)
Grigory_Otrepyev Автор
17.03.2024 20:42А может, раз уж пошла такая пьянка, и если есть опыт, то и про IBM PowerVM напишите?
Стенда нет, и про это лучше спрашивать иногда тут бывающего Господина Инженера.
Fox_exe
Threads = Потоки (выполнения). Давно устоявшийся термин, достаточно точно описывающий суть.
Вот вам ещё интересная тема для исследования (Не совсем KVM, но очень близко):
VirtIO-SCSI + Ext4 = 200МБ/с
VirtIO-SCSI + Fat32 = 500МБ/с
* На хосте SSD на 520-550МБ/с. QEMU-KVM. Все настройки по дефолту. Клиент особой роли не играет, важна только ФС и/или её настройки. Смена размера кластера 512/4096 ни на что не влияет. Замер через банальный DD.
sYB-Tyumen
А в гостевой ОС dd прямо на блочное устройство или в файл на ФС?
Fox_exe
В фс, естественно.
С блоками там другая беда - LVM (thin/thick - ext4/btrfs - всё одинаково) тоже скорость в 2-3 раза режет. Так и не смог победить. В итоге виртуалки свои держу в файлах .raw - так производительность близка к аппаратной.
babarinvv
Судя по цифрам - Misalignment. В первом случае некорректное смещение начальных блоков и во время теста вместо 1 блока каждый раз читается/пишется 2 соседних.
Fox_exe
Речь ведь про это? Пробовал также 1024 и 4096 - без разницы.
Начало раздела выровнено. По крайней мере parted не ругается на это.
orryon
возможно да, только у ssd размер страницы 16KB, так что для выравнивания надо указывать 16384, а 1024/4096 - без разницы, да.
а вообще должен быть выровнен как raw файл, так и fs внутри этого файла. как оно там будет в ext4 внутри raw - надо смотреть.