LINUX.ORG.RU
ФорумAdmin

За счёт чего такой прирост производительности и есть ли он вообще?

 ,


0

2

Тестирую новенький NVME диск в связке с LVM/RAID0

для начала запускаю бенч на корневом разделе который размещён на NVME

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=testfile

test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.28
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=475MiB/s,w=158MiB/s][r=122k,w=40.5k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=967354: Fri Jan 20 16:08:51 2023
  read: IOPS=122k, BW=477MiB/s (500MB/s)(3070MiB/6433msec)
   bw (  KiB/s): min=484400, max=494952, per=100.00%, avg=488777.33, stdev=2638.53, samples=12
   iops        : min=121100, max=123738, avg=122194.33, stdev=659.63, samples=12
  write: IOPS=40.8k, BW=159MiB/s (167MB/s)(1026MiB/6433msec); 0 zone resets
   bw (  KiB/s): min=160680, max=165056, per=100.00%, avg=163478.00, stdev=1347.77, samples=12
   iops        : min=40170, max=41264, avg=40869.50, stdev=336.94, samples=12
  cpu          : usr=21.74%, sys=43.69%, ctx=445460, majf=0, minf=6
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=477MiB/s (500MB/s), 477MiB/s-477MiB/s (500MB/s-500MB/s), io=3070MiB (3219MB), run=6433-6433msec
  WRITE: bw=159MiB/s (167MB/s), 159MiB/s-159MiB/s (167MB/s-167MB/s), io=1026MiB (1076MB), run=6433-6433msec

Disk stats (read/write):
  nvme0n1: ios=781546/261240, merge=0/11, ticks=395602/2057, in_queue=397662, util=98.54%

получаю вот такие скорости чтения/записи:

read: IOPS=122k, BW=477MiB/s (500MB/s)(3070MiB/6433msec)

write: IOPS=40.8k, BW=159MiB/s (167MB/s)(1026MiB/6433msec);

затем создаю 6 пустых балванок

dd if=/dev/zero bs=1500M count=1 of=raid/sda{1..6}.dd

затем монтирую как устройства /dev/loop{15..20} и уже из них делаю LVM/RAID0

lvs -a -o name,copy_percent,devices  vgdata
  LV       Cpy%Sync Devices                                                                                  
  lvmirror          /dev/loop15(0),/dev/loop16(0),/dev/loop17(0),/dev/loop18(0),/dev/loop19(0),/dev/loop20(0)
losetup -l|grep sda
/dev/loop19         0      0         0  0 /root/raid/sda5.dd                                       0     512
/dev/loop17         0      0         0  0 /root/raid/sda3.dd                                       0     512
/dev/loop15         0      0         0  0 /root/raid/sda1.dd                                       0     512
/dev/loop18         0      0         0  0 /root/raid/sda4.dd                                       0     512
/dev/loop16         0      0         0  0 /root/raid/sda2.dd                                       0     512
/dev/loop20         0      0         0  0 /root/raid/sda6.dd                                       0     512

монтирую полученную FS в дирикторию raid

mount |grep raid
/dev/mapper/vgdata-lvmirror on /root/raid type ext4 (rw,relatime,stripe=96)

запускаю бенч уже на этой файловой систем и получаю удвоение производительности

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=testfile

test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.28
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=738MiB/s,w=247MiB/s][r=189k,w=63.2k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=967394: Fri Jan 20 16:09:19 2023
  read: IOPS=190k, BW=743MiB/s (779MB/s)(3070MiB/4130msec)
   bw (  KiB/s): min=750888, max=775560, per=100.00%, avg=761323.00, stdev=7770.14, samples=8
   iops        : min=187722, max=193890, avg=190330.75, stdev=1942.54, samples=8
  write: IOPS=63.6k, BW=248MiB/s (260MB/s)(1026MiB/4130msec); 0 zone resets
   bw (  KiB/s): min=251480, max=259656, per=100.00%, avg=254520.00, stdev=2730.45, samples=8
   iops        : min=62870, max=64914, avg=63630.00, stdev=682.61, samples=8
  cpu          : usr=29.35%, sys=70.53%, ctx=197, majf=0, minf=8
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=743MiB/s (779MB/s), 743MiB/s-743MiB/s (779MB/s-779MB/s), io=3070MiB (3219MB), run=4130-4130msec
  WRITE: bw=248MiB/s (260MB/s), 248MiB/s-248MiB/s (260MB/s-260MB/s), io=1026MiB (1076MB), run=4130-4130msec

Disk stats (read/write):
    dm-0: ios=739484/247392, merge=0/0, ticks=3636/1212, in_queue=4848, util=97.59%, aggrios=130986/43776, aggrmerge=0/0, aggrticks=648/234, aggrin_queue=883, aggrutil=96.38%
  loop19: ios=130874/43894, merge=0/0, ticks=646/233, in_queue=880, util=96.38%
  loop17: ios=131194/43558, merge=0/0, ticks=654/234, in_queue=888, util=96.38%
  loop15: ios=131019/43749, merge=0/0, ticks=651/235, in_queue=886, util=96.38%
  loop18: ios=130916/43848, merge=0/0, ticks=649/240, in_queue=888, util=96.38%
  loop16: ios=131062/43706, merge=0/0, ticks=648/232, in_queue=879, util=96.38%
  loop20: ios=130856/43901, merge=0/0, ticks=644/232, in_queue=877, util=96.38%

получаю вот такие скорости чтения/записи:

read: IOPS=190k, BW=743MiB/s (779MB/s)(3070MiB/4130msec)

write: IOPS=63.6k, BW=248MiB/s (260MB/s)(1026MiB/4130msec);

действительно ли этот тест показывает повышение производительности и за счёт чего оно происходит?

★★

У тебя тест оперирует блоками по 4К. В случае прямого обращения к nvme от так и работает блоками по 4К. В случае использования LVM он начинает работать блоками stripe=96, т.е. 96Кб.

Я бы подумал в эту сторону, но не факт. Хочешь проверить — пересобери raid с меньшим значением stripe.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

ещё не пробовал оперировать размерами блоков, пробовал этот же рейд собирать из разного количества блоков и на разных девайсах [hdd/ssd/nvme] с тестом через gnome-disks

вот такая табличка вышла https://python.breys.ru/page/test_speed_LVM-raid

ps: в gnome-disks стоит дефолтный «Размер фрагмента (МиБ) 20»

fMad ★★
() автор топика
Последнее исправление: fMad (всего исправлений: 2)
Ответ на: комментарий от Aceler

Пересобрал lvm вот так

lvcreate -i6 -I4  -l 100%VG -n lvmirror vgdata

в результате всё равно производительность выше чем NVME

read: IOPS=188k, BW=735MiB/s (771MB/s)(3070MiB/4177msec)
write: IOPS=62.9k, BW=246MiB/s (258MB/s)(1026MiB/4177msec)

io --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=testfile
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.28
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=738MiB/s,w=246MiB/s][r=189k,w=63.0k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=983225: Fri Jan 20 16:56:27 2023
  read: IOPS=188k, BW=735MiB/s (771MB/s)(3070MiB/4177msec)
   bw (  KiB/s): min=730491, max=760520, per=100.00%, avg=753162.38, stdev=9439.28, samples=8
   iops        : min=182622, max=190130, avg=188290.50, stdev=2360.08, samples=8
  write: IOPS=62.9k, BW=246MiB/s (258MB/s)(1026MiB/4177msec); 0 zone resets
   bw (  KiB/s): min=243600, max=254336, per=100.00%, avg=251951.00, stdev=3690.92, samples=8
   iops        : min=60900, max=63584, avg=62987.75, stdev=922.73, samples=8
  cpu          : usr=25.74%, sys=74.21%, ctx=26, majf=0, minf=6
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=735MiB/s (771MB/s), 735MiB/s-735MiB/s (771MB/s-771MB/s), io=3070MiB (3219MB), run=4177-4177msec
  WRITE: bw=246MiB/s (258MB/s), 246MiB/s-246MiB/s (258MB/s-258MB/s), io=1026MiB (1076MB), run=4177-4177msec

Disk stats (read/write):
    dm-0: ios=779062/260324, merge=0/0, ticks=3744/1468, in_queue=5212, util=97.78%, aggrios=130986/43776, aggrmerge=0/0, aggrticks=668/230, aggrin_queue=898, aggrutil=96.38%
  loop19: ios=130974/43789, merge=0/0, ticks=670/233, in_queue=904, util=96.38%
  loop17: ios=131157/43606, merge=0/0, ticks=683/231, in_queue=913, util=96.38%
  loop15: ios=131134/43628, merge=0/0, ticks=661/226, in_queue=888, util=96.38%
  loop18: ios=130802/43961, merge=0/0, ticks=658/233, in_queue=890, util=96.38%
  loop16: ios=130823/43939, merge=0/0, ticks=670/232, in_queue=902, util=96.38%
  loop20: ios=131031/43733, merge=0/0, ticks=666/229, in_queue=896, util=96.38%
fMad ★★
() автор топика
Ответ на: комментарий от bigbit

глубины очереди?

это про размер кеша накопителя?

работу кеша NVME хорошо показывает gnome-disks, там видно что 20% теста запись идёт на очень высокой скорости, а затем очевидно кеш забивается и скорость падает и затем линейна

а fio вообще гоняет файл 4Gb, что не влезет ни в какой кеш девайса

но главное, прирост скорости чтения

fMad ★★
() автор топика
Последнее исправление: fMad (всего исправлений: 1)
Ответ на: комментарий от fMad

Нет. Очередь - это очередь. Вот ты использовал в команде fio ключик –iodepth=64. Не задумывался, что он значит? Ладно, про очередь я наверное фигню написал.

Фишка SSD в том, что он может делать много операций параллельно. Чем больше ты его нагрузаешь параллельными операциями, чем больше IOPS получаешь. RAID-0 - это как раз параллельность.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

Тут очереди ни при чем. По дефолту в линуксе глубина очереди у большинства девайсов вообще 128 так что тс к нему даже близко не подошел. Дело именно в лупдевайсах и пейджкэше

no-dashi-v2 ★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от bigbit

у меня во ссылке этот же эффект есть не только на SSD но на HDD девайсе

ps: мне кажется, что тут дело в том в что в качестве контроллера со своим cpu и mem выступает уже не контроллер, а lvm драйвер, ресурсы которого ограничены конфигой ПК, а не производителем контроллера, но это не точно

fMad ★★
() автор топика
Ответ на: комментарий от bigbit

попробовал, нарезал ssd на 4 раздела, засунул в PV, VG и LVM/raid0 ни какого прироста и это логично

а вот если на этом разделе запилить 4 пустых файла, засунуть из loop и потом в raid0 то появляется нехилый прирост в двух бенмарках

fMad ★★
() автор топика
Ответ на: комментарий от fMad

В fio опцию надо добавлять блин.

И расширенное объеснение: у тебя тест г…но из-за кривых опций, а значит и результаты теста то же самое что и тест, и все выводы и идеи, которые ты можешь сделать и сгенерировать на основе результатов кривого теста, будут тем же самым, чем является тест (коричневым - но не шоколадом).

в качестве контроллера со своим cpu и mem выступает уже не контроллер, а lvm драйвер

Ты блин вообще читать не умеешь? Русским языком тебе выше написал - loop-устройство работает через page cache. Все твои записи попадают в кэш в RAM а не на диск и на диск сливаются позже. LVM тут ни при чем вообще.

no-dashi-v2 ★★
()
Ответ на: комментарий от no-dashi-v2

не психуй

опции fio я взял общепринятые для простого тестирования производительности диска, пользуюсь им давно, со времен hdd, в параметры особо не вдавался, но почему есть догадка что с опцией –fsync=1 она на любом девайсе будет работать крайне медленно

LVM тут ни при чем вообще.

raid0 зато причём

fMad ★★
() автор топика
Последнее исправление: fMad (всего исправлений: 2)
Ответ на: комментарий от fMad

опции fio я взял общепринятые для простого тестирования

Только ты к «простому тестированию» зачем то взял и добавил слой loop-устройств, в результате чего у тебя внезапно оказалось куча (сколько там у тебя в компе) гигабайт кэша.

fsync=1 она на любом девайсе будет работать крайне медленно

Эта опйия покажет тебе реальную производительность диска.

Поэтому либо ты запускаешь fio на стеке БЕЗ loop, либо ты тестируешь шляпу а не диск. И нет - не надо пытаться натянуть полученный якобы «производительный режим» в постоянку - в блочном стеке любой прирост скорости достигается только кратным снижением надежности.

no-dashi-v2 ★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от no-dashi-v2

Только ты к «простому тестированию» зачем то взял и добавил слой loop-устройств, в результате чего у тебя внезапно оказалось куча (сколько там у тебя в компе) гигабайт кэша.

да мне не нужна реальная производительность диска, это же ясно, что нельзя используя hdd накопитель получить скорости выше чем скорость этого накопителя, а вот сделать быстрый ram диск для всяких nod и стимов при избытке гигабайтов оперативки по цене 300 рублей за гб. пробовал на обычном tempfs и ramfs, такого получить не удалось

прирост скорости достигается только кратным снижением надежности.

а почему бы не запускать на таких разделах docker?

fMad ★★
() автор топика
Ответ на: комментарий от fMad

а почему бы не запускать на таких разделах docker?

Потому, что не нужно. Контейнеры по своей идее это стетлессовые сущности, им не нужно много/активно писать, а то что активно читается и так закэшируется. Ну и что немаловажно, у тебя получится двойное кэширование (пейджкэш перед loop + кэш после loop), то есть крайне нерациональное использование оперативки и очень плохая реакция на sync/flush которая будет ставить систему раком на непредсказуемое время.

no-dashi-v2 ★★
()