Pull to refresh

Comments 13

треды (или нити, как лучше сказать то?)

Threads = Потоки (выполнения). Давно устоявшийся термин, достаточно точно описывающий суть.

Вот вам ещё интересная тема для исследования (Не совсем KVM, но очень близко):
VirtIO-SCSI + Ext4 = 200МБ/с
VirtIO-SCSI + Fat32 = 500МБ/с
* На хосте SSD на 520-550МБ/с. QEMU-KVM. Все настройки по дефолту. Клиент особой роли не играет, важна только ФС и/или её настройки. Смена размера кластера 512/4096 ни на что не влияет. Замер через банальный DD.

А в гостевой ОС dd прямо на блочное устройство или в файл на ФС?

В фс, естественно.

С блоками там другая беда - LVM (thin/thick - ext4/btrfs - всё одинаково) тоже скорость в 2-3 раза режет. Так и не смог победить. В итоге виртуалки свои держу в файлах .raw - так производительность близка к аппаратной.

Судя по цифрам - Misalignment. В первом случае некорректное смещение начальных блоков и во время теста вместо 1 блока каждый раз читается/пишется 2 соседних.

mkfs.fat -S 512 /dev/sda4
mkfs.ext4 -b 512 /dev/sda4

Речь ведь про это? Пробовал также 1024 и 4096 - без разницы.
Начало раздела выровнено. По крайней мере parted не ругается на это.

возможно да, только у ssd размер страницы 16KB, так что для выравнивания надо указывать 16384, а 1024/4096 - без разницы, да.

а вообще должен быть выровнен как raw файл, так и fs внутри этого файла. как оно там будет в ext4 внутри raw - надо смотреть.

Для лиги лени

Что-то локальное пикабушное. Почему бы не юзать более распространённое TL;DR?)

Почему автор использует/употребляет не то, что привычно комментатору. Ох, аж флешбеки накатили. Как будто я снова читаю форумы с вопросами и ответы по линуксу в 00-х. Бррр..

столько всего написано в 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 я, в целом, тоже согласен, но за ссылки спасибо ;)

А может, раз уж пошла такая пьянка, и если есть опыт, то и про IBM PowerVM напишите?

Стенда нет, и про это лучше спрашивать иногда тут бывающего Господина Инженера.

Sign up to leave a comment.

Articles