Comments 13
треды (или нити, как лучше сказать то?)
Threads = Потоки (выполнения). Давно устоявшийся термин, достаточно точно описывающий суть.
Вот вам ещё интересная тема для исследования (Не совсем KVM, но очень близко):
VirtIO-SCSI + Ext4 = 200МБ/с
VirtIO-SCSI + Fat32 = 500МБ/с
* На хосте SSD на 520-550МБ/с. QEMU-KVM. Все настройки по дефолту. Клиент особой роли не играет, важна только ФС и/или её настройки. Смена размера кластера 512/4096 ни на что не влияет. Замер через банальный DD.
А в гостевой ОС dd прямо на блочное устройство или в файл на ФС?
Судя по цифрам - Misalignment. В первом случае некорректное смещение начальных блоков и во время теста вместо 1 блока каждый раз читается/пишется 2 соседних.
Для лиги лени
Что-то локальное пикабушное. Почему бы не юзать более распространённое TL;DR?)
столько всего написано в 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 режиму, при этом фактически отказываясь от ООП, от строк и объектов по ссылкам в куче (неважно, управляемой или нет), то есть от динамического неупорядоченного размещения объектов в памяти, возвращаясь к массивам плоских структур, к сбору доменов строк, в которых предполагается поиск, в сплошной текст с параллельным массивом индексов начал/длин - нет. движуха в разработке все ещё идет наоборот, в обратную сторону.
но невозможно распределить ресурс контроллера DRAM - он один на сокет, а часто и на плату вся DRAM подключена к одному, а если и к нескольким - то ещё хуже,
Потому что это так только на дешевых x86, про что было в первой части статьи. На IBM Power и не только - это не так.
4) в режиме виртуализации скорость работы с DRAM падает
Это тоже не так "в целом", только для x86 и то не всегда.
то есть где-то можно задать мультиплексирование контроллера DRAM между ВМ с выделением каждой определенного bandwidth ? где об этом можно прочесть ?
а скорость работы (точнее задания адреса для выборки строки в кэш) с DRAM падает по вполне определенным причинам - вклинивается ещё один слой косвенной адресации страниц. там где не падает - она изначально ниже.
сама то структура работы с DRAM от платформы не зависит - нужен физический адрес строки, по которому она переписывается из внутреннего массива в строку банка, не мгновенно, потом столбца, потом "можно читать".
скорее x86 имеет такой режим, где трансляция логического адреса, используемого в процессе, в физический происходит достаточно быстро, всего 2 уровня разыменования по большому счету. с виртуализацией на 1 больше.
А может, раз уж пошла такая пьянка, и если есть опыт, то и про IBM PowerVM напишите? Ну раз уж в первой статье были отзывы про p720. Меня как-то давно смущает отсутствие баре-метал как класса, хотя с отзывом про производительность я полностью согласен. Про виртуализацию на x86 я, в целом, тоже согласен, но за ссылки спасибо ;)
Тормозящая виртуализация на x86. Небольшая попытка разобраться Часть 4. KVM