Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
disk speed test
12 views
Skip to first unread message
Andrey Mundirov
Feb 27, 2020, 9:35:01 PM2/27/20
to
Здравствуй, All!
Чем сейчас в линуксе модно мерить производительность дисков? fio, iozone или
что-то еще?
Хочу сделать программный RAID1 из двух SSD и сравнить скорость с одиночным
диском. Вроде бы при чтении с рейда должен быть какой-то плюс, но что будет при
записи? И каков будет расход процессора на обслуживание программного рейда при
больших потоках данных? Это и предстоит выяснить.
С наилучшими пожеланиями, Andrey
Чем сейчас в линуксе модно мерить производительность дисков? fio, iozone или
что-то еще?
Хочу сделать программный RAID1 из двух SSD и сравнить скорость с одиночным
диском. Вроде бы при чтении с рейда должен быть какой-то плюс, но что будет при
записи? И каков будет расход процессора на обслуживание программного рейда при
больших потоках данных? Это и предстоит выяснить.
С наилучшими пожеланиями, Andrey
Alexey Fayans
Feb 28, 2020, 6:55:02 AM2/28/20
to
Hello Andrey!
On Fri, 28 Feb 2020 at 03:44 +0300, you wrote to All:
AM> Чем сейчас в линуксе модно мерить производительность дисков? fio,
AM> iozone или что-то еще?
Есть ещё bonnie++ (https://en.wikipedia.org/wiki/Bonnie%2B%2B)
AM> Хочу сделать программный RAID1 из двух SSD и сравнить скорость с
AM> одиночным диском. Вроде бы при чтении с рейда должен быть какой-то
AM> плюс,
Прирост чтения может быть до 2x, при условии, что читаться будет несколько
файлов параллельно.
AM> но что будет при записи?
Никакого прироста, т.к. на оба диска будет писаться одновременно.
AM> И каков будет расход процессора на
AM> обслуживание программного рейда при больших потоках данных?
Настолько незначительный, что не стоит даже думать об этом.
Кстати, у софтверной реализации raid10 (mdadm) есть 2-дисковый вариант. То же
зеркало, только кусочками. В режиме f2 (2 far copies) скорость записи должна
быть получше, чем у обычного зеркала. Есть ещё более новый режим offset, но про
него ничего толком не видел в сети (не особо и искал). Где-то было написано,
что скорость записи должна быть не хуже, чем в режиме far, а чтение лучше. Но
это не точно. :) Возможно, всё это актуально только для обычных дисков, а в
случае с SSD разницы вообще никакой не будет.
... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
On Fri, 28 Feb 2020 at 03:44 +0300, you wrote to All:
AM> Чем сейчас в линуксе модно мерить производительность дисков? fio,
AM> iozone или что-то еще?
Есть ещё bonnie++ (https://en.wikipedia.org/wiki/Bonnie%2B%2B)
AM> Хочу сделать программный RAID1 из двух SSD и сравнить скорость с
AM> одиночным диском. Вроде бы при чтении с рейда должен быть какой-то
AM> плюс,
Прирост чтения может быть до 2x, при условии, что читаться будет несколько
файлов параллельно.
AM> но что будет при записи?
Никакого прироста, т.к. на оба диска будет писаться одновременно.
AM> И каков будет расход процессора на
AM> обслуживание программного рейда при больших потоках данных?
Настолько незначительный, что не стоит даже думать об этом.
Кстати, у софтверной реализации raid10 (mdadm) есть 2-дисковый вариант. То же
зеркало, только кусочками. В режиме f2 (2 far copies) скорость записи должна
быть получше, чем у обычного зеркала. Есть ещё более новый режим offset, но про
него ничего толком не видел в сети (не особо и искал). Где-то было написано,
что скорость записи должна быть не хуже, чем в режиме far, а чтение лучше. Но
это не точно. :) Возможно, всё это актуально только для обычных дисков, а в
случае с SSD разницы вообще никакой не будет.
... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
Andrey Mundirov
Feb 28, 2020, 10:45:02 AM2/28/20
to
Здравствуй, Alexey!
Ответ на сообщение Alexey Fayans (2:5030/1997) к Andrey Mundirov, написанное 28
фев 20 в 14:28:
AF> Прирост чтения может быть до 2x, при условии, что читаться будет
AF> несколько файлов параллельно.
AM>> но что будет при записи?
AF> Никакого прироста, т.к. на оба диска будет писаться одновременно.
А падения не будет?
AM>> И каков будет расход процессора на
AM>> обслуживание программного рейда при больших потоках данных?
AF> Настолько незначительный, что не стоит даже думать об этом.
Помню, во времена IDE дисков я укладывал дисковыми операциями сразу 2 ядра на
100%. И с тех пор юзал программный рейд только в малонагруженных местах. Но
сейчас не тот случай.
В любом случае, железо уже у меня в руках, буду тестить, о результатах
отпишусь.
С наилучшими пожеланиями, Andrey
Ответ на сообщение Alexey Fayans (2:5030/1997) к Andrey Mundirov, написанное 28
фев 20 в 14:28:
AF> Прирост чтения может быть до 2x, при условии, что читаться будет
AF> несколько файлов параллельно.
AM>> но что будет при записи?
А падения не будет?
AM>> И каков будет расход процессора на
AM>> обслуживание программного рейда при больших потоках данных?
Помню, во времена IDE дисков я укладывал дисковыми операциями сразу 2 ядра на
100%. И с тех пор юзал программный рейд только в малонагруженных местах. Но
сейчас не тот случай.
В любом случае, железо уже у меня в руках, буду тестить, о результатах
отпишусь.
С наилучшими пожеланиями, Andrey
Alexey Fayans
Feb 28, 2020, 12:30:01 PM2/28/20
to
Hello Andrey!
On Fri, 28 Feb 2020 at 18:20 +0300, you wrote to me:
AM>>> но что будет при записи?
AF>> Никакого прироста, т.к. на оба диска будет писаться одновременно.
AM> А падения не будет?
Если с железом проблем нет и скорость записи на один диск не зависит от того,
пишется ли что-то на другой, и наоборот, то не будет. Такие проблемы, кажется,
были только во времена IDE интерфейсов.. :)
AM>>> И каков будет расход процессора на
AM>>> обслуживание программного рейда при больших потоках данных?
AF>> Настолько незначительный, что не стоит даже думать об этом.
AM> Помню, во времена IDE дисков я укладывал дисковыми операциями сразу 2
AM> ядра на 100%. И с тех пор юзал программный рейд только в
AM> малонагруженных местах. Но сейчас не тот случай.
Возможно, когда всё работало в режиме PIO, это было реально. В режиме DMA проц
уже не нагружался.
AM> В любом случае, железо уже у меня в руках, буду тестить, о результатах
AM> отпишусь.
Окей. :)
On Fri, 28 Feb 2020 at 18:20 +0300, you wrote to me:
AM>>> но что будет при записи?
AF>> Никакого прироста, т.к. на оба диска будет писаться одновременно.
Если с железом проблем нет и скорость записи на один диск не зависит от того,
пишется ли что-то на другой, и наоборот, то не будет. Такие проблемы, кажется,
были только во времена IDE интерфейсов.. :)
AM>>> И каков будет расход процессора на
AM>>> обслуживание программного рейда при больших потоках данных?
AF>> Настолько незначительный, что не стоит даже думать об этом.
AM> ядра на 100%. И с тех пор юзал программный рейд только в
AM> малонагруженных местах. Но сейчас не тот случай.
Возможно, когда всё работало в режиме PIO, это было реально. В режиме DMA проц
уже не нагружался.
AM> В любом случае, железо уже у меня в руках, буду тестить, о результатах
AM> отпишусь.
Окей. :)
Andrey Mundirov
Mar 2, 2020, 10:15:01 AM3/2/20
to
Здравствуй, All!
Ответ на сообщение Alexey Fayans (2:5030/1997) к Andrey Mundirov, написанное 28
фев 20 в 20:13:
AF> Hello Andrey!
AF> On Fri, 28 Feb 2020 at 18:20 +0300, you wrote to me:
AM>>>> но что будет при записи?
AF>>> Никакого прироста, т.к. на оба диска будет писаться
AF>>> одновременно.
AF> от того, пишется ли что-то на другой, и наоборот, то не будет. Такие
AF> проблемы, кажется, были только во времена IDE интерфейсов.. :)
AM>>>> И каков будет расход процессора на
AM>>>> обслуживание программного рейда при больших потоках данных?
AF>>> Настолько незначительный, что не стоит даже думать об этом.
Протестил, получил неожиданные результаты
Подопытные: два одинаковых Western Digital PC SN720 NVMe SSD
Тестировал командой:
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test
--filename=test --bs=4k --iodepth=64 --size=8G --readwrite=randrw
--rwmixread=75 --loops=10
ОС: CentOS 7.1908 LiveDVD
> Тест одного диска:
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B,
ioengine=libaio, iodepth=64
fio-3.7
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=689MiB/s,w=231MiB/s][r=176k,w=59.2k IOPS][eta
00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=4814: Fri Feb 28 17:48:47 2020
> read: IOPS=177k, BW=693MiB/s (726MB/s)(59.0GiB/88677msec)
bw ( KiB/s): min=671896, max=726344, per=100.00%, avg=709183.07,
stdev=9236.61, samples=177
iops : min=167974, max=181586, avg=177295.76, stdev=2309.12,
samples=177
> write: IOPS=59.2k, BW=231MiB/s (243MB/s)(20.0GiB/88677msec)
bw ( KiB/s): min=224008, max=243952, per=100.00%, avg=236823.12,
stdev=3447.63, samples=177
iops : min=56002, max=60988, avg=59205.78, stdev=861.91, samples=177
> cpu : usr=30.09%, sys=50.02%, ctx=2644759, majf=0, minf=30
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=15721450,5250070,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=693MiB/s (726MB/s), 693MiB/s-693MiB/s (726MB/s-726MB/s), io=59.0GiB
(64.4GB), run=88677-88677msec
WRITE: bw=231MiB/s (243MB/s), 231MiB/s-231MiB/s (243MB/s-243MB/s), io=20.0GiB
(21.5GB), run=88677-88677msec
Disk stats (read/write):
nvme1n1: ios=15711850/5246888, merge=0/17, ticks=5307634/51745,
in_queue=5357697, util=99.92%
> Тест RAID1 из двух дисков, параметры RAID по умолчанию:
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B,
ioengine=libaio, iodepth=64
fio-3.7
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=609MiB/s,w=205MiB/s][r=156k,w=52.4k IOPS][eta
00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=5197: Fri Feb 28 18:44:32 2020
> read: IOPS=153k, BW=597MiB/s (626MB/s)(59.0GiB/102800msec)
bw ( KiB/s): min=427880, max=635832, per=100.00%, avg=611724.82,
stdev=29930.98, samples=205
iops : min=106970, max=158958, avg=152931.22, stdev=7482.75,
samples=205
> write: IOPS=51.1k, BW=199MiB/s (209MB/s)(20.0GiB/102800msec)
bw ( KiB/s): min=142866, max=212080, per=100.00%, avg=204281.47,
stdev=10302.75, samples=205
iops : min=35716, max=53020, avg=51070.36, stdev=2575.69, samples=205
> cpu : usr=27.76%, sys=63.37%, ctx=1430800, majf=0, minf=30
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=15721450,5250070,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=597MiB/s (626MB/s), 597MiB/s-597MiB/s (626MB/s-626MB/s), io=59.0GiB
(64.4GB), run=102800-102800msec
WRITE: bw=199MiB/s (209MB/s), 199MiB/s-199MiB/s (209MB/s-209MB/s), io=20.0GiB
(21.5GB), run=102800-102800msec
Disk stats (read/write):
md0: ios=15695521/5241462, merge=0/0, ticks=0/0, in_queue=0, util=0.00%,
aggrios=7860725/5250263, aggrmerge=0/20, aggrticks=2942430/46197,
aggrin_queue=2986704, aggrutil=99.92%
nvme0n1: ios=7873231/5250263, merge=0/20, ticks=2971705/37500,
in_queue=3007131, util=99.92%
nvme1n1: ios=7848219/5250263, merge=0/20, ticks=2913155/54894,
in_queue=2966278, util=99.91%
Внезапно вместо прироста скорости чтения обнаружилось некоторое замедление.
Загрузка процессора тоже подросла, но не так сильно, как я ожидал. Наверно,
надо как-то тюнить рейд, изучать вопрос.
И следующий вопрос - как с этой хрени загрузиться, но это я буду отдельно
читать мануалы по UEFI и всему гемору, связанному с ним.
С наилучшими пожеланиями, Andrey
Ответ на сообщение Alexey Fayans (2:5030/1997) к Andrey Mundirov, написанное 28
AF> Hello Andrey!
AF> On Fri, 28 Feb 2020 at 18:20 +0300, you wrote to me:
AM>>>> но что будет при записи?
AF>>> Никакого прироста, т.к. на оба диска будет писаться
AM>> А падения не будет?
AF> Если с железом проблем нет и скорость записи на один диск не зависит
AF> от того, пишется ли что-то на другой, и наоборот, то не будет. Такие
AF> проблемы, кажется, были только во времена IDE интерфейсов.. :)
AM>>>> И каков будет расход процессора на
AM>>>> обслуживание программного рейда при больших потоках данных?
AF>>> Настолько незначительный, что не стоит даже думать об этом.
Подопытные: два одинаковых Western Digital PC SN720 NVMe SSD
Тестировал командой:
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test
--filename=test --bs=4k --iodepth=64 --size=8G --readwrite=randrw
--rwmixread=75 --loops=10
ОС: CentOS 7.1908 LiveDVD
> Тест одного диска:
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B,
ioengine=libaio, iodepth=64
fio-3.7
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=689MiB/s,w=231MiB/s][r=176k,w=59.2k IOPS][eta
00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=4814: Fri Feb 28 17:48:47 2020
> read: IOPS=177k, BW=693MiB/s (726MB/s)(59.0GiB/88677msec)
bw ( KiB/s): min=671896, max=726344, per=100.00%, avg=709183.07,
stdev=9236.61, samples=177
iops : min=167974, max=181586, avg=177295.76, stdev=2309.12,
samples=177
> write: IOPS=59.2k, BW=231MiB/s (243MB/s)(20.0GiB/88677msec)
bw ( KiB/s): min=224008, max=243952, per=100.00%, avg=236823.12,
stdev=3447.63, samples=177
iops : min=56002, max=60988, avg=59205.78, stdev=861.91, samples=177
> cpu : usr=30.09%, sys=50.02%, ctx=2644759, majf=0, minf=30
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=15721450,5250070,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=693MiB/s (726MB/s), 693MiB/s-693MiB/s (726MB/s-726MB/s), io=59.0GiB
(64.4GB), run=88677-88677msec
WRITE: bw=231MiB/s (243MB/s), 231MiB/s-231MiB/s (243MB/s-243MB/s), io=20.0GiB
(21.5GB), run=88677-88677msec
Disk stats (read/write):
nvme1n1: ios=15711850/5246888, merge=0/17, ticks=5307634/51745,
in_queue=5357697, util=99.92%
> Тест RAID1 из двух дисков, параметры RAID по умолчанию:
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B,
ioengine=libaio, iodepth=64
fio-3.7
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=609MiB/s,w=205MiB/s][r=156k,w=52.4k IOPS][eta
00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=5197: Fri Feb 28 18:44:32 2020
> read: IOPS=153k, BW=597MiB/s (626MB/s)(59.0GiB/102800msec)
bw ( KiB/s): min=427880, max=635832, per=100.00%, avg=611724.82,
stdev=29930.98, samples=205
iops : min=106970, max=158958, avg=152931.22, stdev=7482.75,
samples=205
> write: IOPS=51.1k, BW=199MiB/s (209MB/s)(20.0GiB/102800msec)
bw ( KiB/s): min=142866, max=212080, per=100.00%, avg=204281.47,
stdev=10302.75, samples=205
iops : min=35716, max=53020, avg=51070.36, stdev=2575.69, samples=205
> cpu : usr=27.76%, sys=63.37%, ctx=1430800, majf=0, minf=30
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=15721450,5250070,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=597MiB/s (626MB/s), 597MiB/s-597MiB/s (626MB/s-626MB/s), io=59.0GiB
(64.4GB), run=102800-102800msec
WRITE: bw=199MiB/s (209MB/s), 199MiB/s-199MiB/s (209MB/s-209MB/s), io=20.0GiB
(21.5GB), run=102800-102800msec
Disk stats (read/write):
md0: ios=15695521/5241462, merge=0/0, ticks=0/0, in_queue=0, util=0.00%,
aggrios=7860725/5250263, aggrmerge=0/20, aggrticks=2942430/46197,
aggrin_queue=2986704, aggrutil=99.92%
nvme0n1: ios=7873231/5250263, merge=0/20, ticks=2971705/37500,
in_queue=3007131, util=99.92%
nvme1n1: ios=7848219/5250263, merge=0/20, ticks=2913155/54894,
in_queue=2966278, util=99.91%
Внезапно вместо прироста скорости чтения обнаружилось некоторое замедление.
Загрузка процессора тоже подросла, но не так сильно, как я ожидал. Наверно,
надо как-то тюнить рейд, изучать вопрос.
И следующий вопрос - как с этой хрени загрузиться, но это я буду отдельно
читать мануалы по UEFI и всему гемору, связанному с ним.
С наилучшими пожеланиями, Andrey
Alexey Vissarionov
Mar 2, 2020, 11:00:02 AM3/2/20
to
Доброго времени суток, Andrey!
02 Mar 2020 17:23:34, ты -> All:
AM> Внезапно вместо прироста скорости чтения обнаружилось некоторое
AM> замедление. Загрузка процессора тоже подросла, но не так сильно,
AM> как я ожидал. Наверно, надо как-то тюнить рейд, изучать вопрос.
Надо.
man mdadm
man blkdev
AM> И следующий вопрос - как с этой хрени загрузиться, но это я буду
AM> отдельно читать мануалы по UEFI и всему гемору, связанному с ним.
Отключаешь secure boot (ну, или создаешь свой CA и выписываешь сертификаты),
собираешь зеркало /dev/md0 (128...256 Мб, строго FAT32), кладешь syslinux.efi
как EFI/Boot/bootx64.efi и рядом с ним ldlinux.c32 libutil.c32 menu.c32, а в
корень этого раздела syslinux.cfg и сами ядра.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Смайлики - тоже знаки препинания :-)
02 Mar 2020 17:23:34, ты -> All:
AM> Внезапно вместо прироста скорости чтения обнаружилось некоторое
AM> замедление. Загрузка процессора тоже подросла, но не так сильно,
AM> как я ожидал. Наверно, надо как-то тюнить рейд, изучать вопрос.
Надо.
man mdadm
man blkdev
AM> И следующий вопрос - как с этой хрени загрузиться, но это я буду
AM> отдельно читать мануалы по UEFI и всему гемору, связанному с ним.
Отключаешь secure boot (ну, или создаешь свой CA и выписываешь сертификаты),
собираешь зеркало /dev/md0 (128...256 Мб, строго FAT32), кладешь syslinux.efi
как EFI/Boot/bootx64.efi и рядом с ним ldlinux.c32 libutil.c32 menu.c32, а в
корень этого раздела syslinux.cfg и сами ядра.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Смайлики - тоже знаки препинания :-)
0 new messages