+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Хочется по душе VirtIOFS, но..., Proxmox Виртуальная Среда

micush

Guest

09.04.2025 17:53:00

Работает просто жутко медленно по сравнению с NFS. В моих тестах с FIO производительность ниже чем в четыре раза. Хочется использовать, потому что кажется более чистой реализацией для обмена файлами с хостом. Но такую огромную потерю производительности я не выдержу. Жаль, правда.

DIRECT: server:/mnt/server1:# show disk perf . 1G
Физический сервер
Тестирование хранилища: /mnt/server1
Тестируемый размер: 1G
Read Performance: 182MB/s IOPS=44.5k
Write Performance: 98.3MB/s IOPS=24.0k

NFS: server:/mnt/server1:# show disk perf . 1G
Стандартный PC QEMU (Q35 + ICH9, 2009)
Тестирование хранилища: /mnt/server1
Тестируемый размер: 1G
Read Performance: 101MB/s IOPS=24.6k
Write Performance: 54.3MB/s IOPS=13.3k

VIRTIOFS: server:/mnt/server11:# show disk perf . 1G
Стандартный PC QEMU (Q35 + ICH9, 2009)
Тестирование хранилища: /mnt/server11
Тестируемый размер: 1G
Read Performance: 26.4MB/s IOPS=6444
Write Performance: 14.2MB/s IOPS=3474

FIO_COMMANDLINE: fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test.file --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=65

xytras Guest	#2 0 09.04.2025 18:05:00 Ой, больно…

rzmeu

Guest

10.04.2025 02:15:00

@micush Ты пробовал использовать кэш? У меня производительность примерно такая же, как у SCSI-дисков на моей ВМ. Но, возможно, я использую не тот протокол/кэш для дисков ВМ. Virtiofs:

Диск ВМ (нужно разобраться, может быть VirtIO Block лучше, и кэш-стратегия тоже):

micush Guest	#4 0 10.04.2025 04:17:00 Да. Кэш=всегда включен. В качестве хранилища используется ZFS draid2.

devilkin Guest	#5 0 10.04.2025 16:03:00 Хотя мои результаты не такие уж и впечатляющие, я тоже вижу снижение пропускной способности на +- 50% при использовании NFSv4.

rzmeu

Guest

10.04.2025 17:38:00

Для меня это приемлемо, я всё настроил так, что это не вызывает никаких проблем. Несколько дисков смонтированы на хосте. Точки монтирования подключены к LXC с Samba, так что я получаю полную производительность, выжимая максимум из 10Gb соединения в моей локальной сети. Те же диски также смонтированы на VM с virtiofs, там у меня Plex, торрент-клиент и другие приложения, использующие медиаданные на этих дисках. Использую хукскрипты уже полгода, и проблем не было.

micush Guest	#7 0 10.04.2025 19:13:00 Как я уже говорил, я хочу использовать virtiofs и отказаться от NFS для этой конкретной задачи, но потеря производительности для меня слишком велика.

rzmeu Guest	#8 0 11.04.2025 22:01:00 @micush У меня почти такая же производительность, как у тебя, если включена опция "Allow Direct IO". У тебя она включена?

micush Guest	#9 0 12.04.2025 01:49:00 Здесь нет поддержки прямого доступа к оборудованию…

alexskysilk

Guest

#10

12.04.2025 05:26:00

Я повторил тест ОР ("Включён прямой доступ к диску"). Коротко: могу подтвердить. В этом тесте virtiofs показывает 38,7% IOPS по сравнению с NFS. Это ощутимая разница для файловой системы, смонтированной через virtiofs:
```
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=./test --filename=test.file --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=65
./test: (g=0): rw=randrw, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.35
Starting 1 process
Jobs: 1 (f=1): [m(1)][96.0%][r=38.9MiB/s,w=21.0MiB/s][r=9971,w=5373 IOPS][eta 00m:01s]
./test: (groupid=0, jobs=1): err= 0: pid=18436: Fri Apr 11 20:17:41 2025
read: IOPS=7212, BW=28.2MiB/s (29.5MB/s)(665MiB/23615msec)
bw ( KiB/s): min= 3768, max=57656, per=100.00%, avg=29376.35, stdev=12237.29, samples=46
iops : min= 942, max=14414, avg=7344.09, stdev=3059.32, samples=46
write: IOPS=3888, BW=15.2MiB/s (15.9MB/s)(359MiB/23615msec); 0 zone resets
bw ( KiB/s): min= 1912, max=31096, per=100.00%, avg=15838.26, stdev=6580.58, samples=46
iops : min= 478, max= 7774, avg=3959.57, stdev=1645.14, samples=46
cpu : usr=1.90%, sys=14.91%, ctx=258076, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=170317,91827,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
READ: bw=28.2MiB/s (29.5MB/s), 28.2MiB/s-28.2MiB/s (29.5MB/s-29.5MB/s), io=665MiB (698MB), run=23615-23615msec
WRITE: bw=15.2MiB/s (15.9MB/s), 15.2MiB/s-15.2MiB/s (15.9MB/s-15.9MB/s), io=359MiB (376MB), run=23615-23615msec to the same filesystem, nfs mounted:
```
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=./test --filename=test.file --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=65
./test: (g=0): rw=randrw, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.35
Starting 1 process
./test: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=71.9MiB/s,w=39.3MiB/s][r=18.4k,w=10.1k IOPS][eta 00m:00s]
./test: (groupid=0, jobs=1): err= 0: pid=18416: Fri Apr 11 20:16:17 2025
read: IOPS=18.6k, BW=72.5MiB/s (76.0MB/s)(665MiB/9181msec)
bw ( KiB/s): min=10264, max=102192, per=99.29%, avg=73678.67, stdev=23963.59, samples=18
iops : min= 2566, max=25548, avg=18419.67, stdev=5990.90, samples=18
write: IOPS=10.0k, BW=39.1MiB/s (41.0MB/s)(359MiB/9181msec); 0 zone resets
bw ( KiB/s): min= 1912, max=31096, per=100.00%, avg=15838.26, stdev=6580.58, samples=46
iops : min= 478, max= 7774, avg=3959.57, stdev=1645.14, samples=46
cpu : usr=1.90%, sys=14.91%, ctx=258076, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=170317,91827,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
READ: bw=72.5MiB/s (76.0MB/s), 72.5MiB/s-72.5MiB/s (76.0MB/s-76.0MB/s), io=665MiB (698MB), run=9181-9181msec
WRITE: bw=39.1MiB/s (41.0MB/s), 39.1MiB/s-39.1MiB/s (41.0MB/s-41.0MB/s), io=359MiB (376MB), run=9181-9181msec

Ramalama Guest	#11 0 12.04.2025 06:34:00 Надеялся, что наконец-то избавись от NFS, но после прочтения этого, virtiofs кажется бессмысленным

scyto

Guest

#12

13.04.2025 05:22:00

Зависит от нагрузки — эту документацию по дизайну читал, и вроде как она рассчитана на легковесные сценарии использования, типа ВМ с контейнерами. Именно это упоминалось в одной из презентаций, которые я видел, и, к слову, это именно то, для чего она мне и нужна (чтобы заменить glusterFS внутри моих ВМ с Docker).

rzmeu

Guest

#13

14.04.2025 23:15:00

Но ОР сказал, что "Allow Direct IO" не включена. Непонятно, почему у него такая плохая производительность. Вот что я получаю для каталога на Samsung 970 EVO 500GB, смонтированном с cache=always:

```
Code: fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test.file --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=65
test: (g=0): rw=randrw, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.36
Starting 1 process
test: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=135MiB/s,w=72.3MiB/s][r=34.4k,w=18.5k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=1050: Mon Apr 14 20:51:14 2025
read: IOPS=34.4k, BW=134MiB/s (141MB/s)(665MiB/4958msec)
bw ( KiB/s): min=133688, max=141688, per=100.00%, avg=137527.11, stdev=2873.66, samples=9
iops : min=33422, max=35422, avg=34381.78, stdev=718.42, samples=9
write: IOPS=18.5k, BW=72.3MiB/s (75.9MB/s)(359MiB/4958msec); 0 zone resets
bw ( KiB/s): min=70920, max=76168, per=99.96%, avg=74053.33, stdev=1752.99, samples=9
iops : min=17730, max=19042, avg=18513.33, stdev=438.25, samples=9
cpu : usr=16.93%, sys=45.47%, ctx=168732, majf=0, minf=10
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=170317,91827,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
READ: bw=134MiB/s (141MB/s), 134MiB/s-134MiB/s (141MB/s-141MB/s), io=665MiB (698MB), run=4958-4958msec
WRITE: bw=72.3MiB/s (75.9MB/s), 72.3MiB/s-72.3MiB/s (75.9MB/s-75.9MB/s), io=359MiB (376MB), run=4958-4958msec
```

Я храню свои медиафайлы на дисках, смонтированных через virtiofs. Qbittorrent и Plex работают отлично. Для повышения скорости я также использую общие диски LXC через точки монтирования, если это необходимо (для запуска Samba).

alexskysilk

Guest

#14

15.04.2025 01:43:00

Не самый важный фактор. Не самый важный фактор и при монтировании той же файловой системы через NFS и повторном запуске бенчмарка. Ни я, ни кто-либо другой не говорит, что virtiofs недостаточно быстр для какого-либо приложения, просто он заметно медленнее других способов подключения.

rzmeu

Guest

#15

15.04.2025 19:04:00

Сделал это, получаю почти одинаковые результаты, используя команду fio, предоставленную OP. Вот что я имею для NFS, которая настроена внутри LXC с точкой монтирования на тот же диск: Код: /mnt/drive *(rw,async,no_subtree_check,no_root_squash) Это конфигурация для virtiofs в настройках VM: Код: cache=always

Раскрыть: Результаты

Хост: Код: fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test.file --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=65

test: (g=0): rw=randrw, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.33
Запуск 1 процесса
test: Размещение IO-файла (1 файл / 1024MiB)
Задачи: 1 (f=1)
test: (groupid=0, jobs=1): err= 0: pid=49844: Вт Apr 15 20:03:35 2025
read: IOPS=130k, BW=509MiB/s (534MB/s)(665MiB/1306msec)
bw ( KiB/s): min=460800, max=544640, per=99.91%, avg=502563.78, stdev=19622.64, samples=9
iops : min=115200, max=136100, avg=128200, stdev=4000, samples=9
write: IOPS=71.3k, BW=323MiB/s (338MB/s)(359MiB/1306msec); 0 zone resets
bw ( KiB/s): min=296960, max=383120, per=99.89%, avg=330000.38, stdev=11939.49, samples=9
iops : min=74240, max=95760, avg=81920, stdev=3136, samples=9
cpu : usr=21.38%, sys=42.18%, ctx=432128, majf=0, minf=10
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=170317,91827,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
READ: bw=509MiB/s (534MB/s), 509MiB/s-509MiB/s (534MB/s-534MB/s), io=665MiB (698MB), run=1306-1306msec
WRITE: bw=323MiB/s (338MB/s), 323MiB/s-323MiB/s (338MB/s-338MB/s), io=359MiB (376MB), run=1306-1306msec

Virtiofs: Код: fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test.file --bs=4k --iodepth=32 --size=1G --readwrite=randrw --rwmixread=65

test: (g=0): rw=randrw, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.36
Запуск 1 процесса
test: Размещение IO-файла (1 файл / 1024MiB)
Задачи: 1 (f=1)
test: (groupid=0, jobs=1): err= 0: pid=1194: Вт Apr 15 16:53:22 2025
read: IOPS=37.2k, BW=145MiB/s (152MB/s)(665MiB/4579msec)
bw ( KiB/s): min=132280, max=167096, per=99.84%, avg=148542.22, stdev=13506.06, samples=9
iops : min=33070, max=41774, avg=37135.56, stdev=3376.51, samples=9
write: IOPS=20.1k, BW=78.3MiB/s (82.1MB/s)(359MiB/4579msec); 0 zone resets
bw ( KiB/s): min=71456, max=89568, per=99.83%, avg=80081.78, stdev=7516.44, samples=9
iops : min=17864, max=22392, avg=20020.44, stdev=1879.11, samples=9
cpu : usr=18.09%, sys=45.63%, ctx=186848, majf=0, minf=8
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=170317,91827,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
READ: bw=145MiB/s (152MB/s), 145MiB/s-145MiB/s (152MB/s-152MB/s), io=665MiB (698MB), run=4579-4579msec
WRITE: bw=78.3MiB/s (82.1MB/s), 78.3MiB/s-78.3MiB/s (82.1MB/s-82.1MB/s), io=359MiB (376MB), run=4579-4579msec

alexskysilk Guest	#16 0 15.04.2025 19:17:00 О, интересно. Попробую пересдать тест и выложу результаты.

scyto

Guest

#17

16.04.2025 17:38:00

Действительно, мне тоже не совсем понятно, есть ли здесь что-то новое по сравнению с проблемами скорости, помеченными как "не будет исправлено" в проекте virtiofs за многие годы. Я немного запутался с DAX и если/как это включено в интерфейсе Proxmox. Это то же самое, что один из режимов кэширования или настройка directio? Кажется, DAX помогает только в определенных сценариях. У вас есть какое-то мнение о том, какой режим кэширования был бы разумным в защищенной системе с ИБП с управляемым отключением (сейчас я не использую ни один)?

scyto Guest	#18 0 17.04.2025 19:50:00 У меня пока нет четкого понимания кэширования и virtioFS. Как ты считаешь, какие режимы кэширования предпочтительнее с точки зрения безопасности записи по сравнению, скажем, с NFS?

rzmeu

Guest

#19

17.04.2025 22:09:00

Я недостаточно компетентен, чтобы рекомендовать это, и не стал бы использовать это на данных, которые мне жалко потерять. Я все еще использую cache=auto, которое настроил полгода назад с помощью хук-скриптов. По сравнению с опцией "always", auto теряет около 21% производительности, если использовать команду fio от OP. Если у тебя с NFS проблем нет, то не вижу смысла мигрировать, потому что с virtiofs ты не получишь лучшей производительности.

scyto Guest	#20 0 17.04.2025 22:24:00 @rzmeu спасибо, это помогает. Мой сценарий немного отличается: у меня есть Docker Swarm VM, в которых сейчас установлен glusterFS, который я использую для bind mounts / постоянных данных в Docker контейнерах. Я никогда не использовал NFS для этих целей. Я перехожу на cephFS по целому ряду причин. Я начинаю с VirtioFS, чтобы выставить cephFS том на хостах Proxmox для Docker Swarm VM. Получилось, работает отлично, мой WordPress контейнер и база данных, работающие в Docker VM, работают без проблем. Это будет сравниваться с: использованием cephFS volume driver (кто-то сейчас над этим работает), установкой cephFS fuse клиента в Docker Swarm VM, использованием cephFS драйвера в режиме ядра. Эти последние два варианта, я надеюсь, никогда не будут обращаться к сети, и весь ввод/вывод будет происходить в ядре хоста Proxmox (т.е. будет быстрым). В какой-то момент я попробую подключить все три варианта к одной cephFS файловой системе и протестирую. Спасибо за ваш вклад, оставлю все на авто, надежность сейчас важнее скорости.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры