LINUX.ORG.RU

Опять медленная скорость работы ZFS

 ,


0

2

Привет.
Очередная проблема с ZFS, дошедшая до абсурда.
Имеем двухсокетный сервак на амд, 64гб рамы, все митигации спекулятивных уязвимостей выключены. После чего создаем в этой раме 3 файла ака диска, из которых соберем raidz1, ну и докинем еще slog по необходимости:

me@moon:/tank$ cd /dev/shm/
me@moon:/dev/shm$ sudo dd if=/dev/zero of=/dev/shm/disk1.img bs=1M count=4096
[sudo] password for smd:
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.7159 s, 1.6 GB/s
me@moon:/dev/shm$ sudo dd if=/dev/zero of=/dev/shm/disk2.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.70449 s, 1.6 GB/s
me@moon:/dev/shm$ sudo dd if=/dev/zero of=/dev/shm/disk3.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.69832 s, 1.6 GB/s
me@moon:/dev/shm$ sudo dd if=/dev/zero of=/dev/shm/slog.img bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 2.7063 s, 1.6 GB/s
me@moon:/dev/shm$ sudo zpool create -o ashift=12 -O compression=off -O atime=off test-pool raidz1 /dev/shm/disk1.img  /dev/shm/disk2.img /dev/shm/disk3.img
me@moon:/dev/shm$ cd /test-pool/
me@moon:/test-pool$ sudo fio --filename=test --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=10G --runtime=300 && rm test
test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=4
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 10240MiB)
^Cbs: 1 (f=1): [W(1)][5.0%][w=25.6MiB/s][w=6565 IOPS][eta 04m:45s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=19078: Fri Jun 21 09:59:34 2019
  write: IOPS=6311, BW=24.7MiB/s (25.9MB/s)(381MiB/15441msec); 0 zone resets
    clat (usec): min=92, max=52087, avg=156.36, stdev=370.36
     lat (usec): min=92, max=52087, avg=156.67, stdev=370.37
    clat percentiles (usec):
     |  1.00th=[  119],  5.00th=[  128], 10.00th=[  133], 20.00th=[  139],
     | 30.00th=[  143], 40.00th=[  145], 50.00th=[  149], 60.00th=[  153],
     | 70.00th=[  157], 80.00th=[  163], 90.00th=[  176], 95.00th=[  194],
     | 99.00th=[  243], 99.50th=[  269], 99.90th=[  392], 99.95th=[  644],
     | 99.99th=[ 2180]
   bw (  KiB/s): min=22520, max=27768, per=100.00%, avg=25287.87, stdev=1354.58, samples=30
   iops        : min= 5630, max= 6942, avg=6321.93, stdev=338.68, samples=30
  lat (usec)   : 100=0.01%, 250=99.23%, 500=0.70%, 750=0.04%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 50=0.01%, 100=0.01%
  cpu          : usr=2.53%, sys=41.02%, ctx=97548, majf=0, minf=17
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,97453,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=4

Т.е. при скорости записи в раму на уровне 1.5GB/s, итоговая скорость записи массива меньше в 50 раз, что настораживает.
Это, конечно, не главная цель, но шажок к тому, чтобы разобраться, отчего дисковая подсистема на сервере такая медленная.
Вопрос, что происходит и что я делаю не так.
В тред приглашаются эксперты: EvgGad_303, axelroot, stave, int13h, DALDON, Dimez, King_Carlo, mord0d, anc, andyl, iron, iZEN .

mord0d

Я же подписан на тег.

Опять медленная скорость работы ZFS

Що значед «опять»?

Во-первых…

zfsonlinux

Разве в ядре не зопретили ZFS?

Во-вторых работа ZFS в файлах никогда и не была быстрой.

В-третьих:

fio

Тут недавно @Harliff тестировал им, и тоже были низкие показатели. За историей и её исходом не следил.

mord0d ()

Повторил на ноуте (правда с другим размером пула). Результат:
write: IOPS=5529, BW=21.6MiB/s (22.7MB/s)(1024MiB/47404msec)
Запись в память такая же — 1,6 GB/s

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

Що значед «опять»?

Потому что это вечная проблема с ZFS. Для примера вот есть дядька(https://martin.heiland.io/2018/02/23/zfs-tuning/), у которого скорости в несколько раз выше даже на шпинделях, что выглядит очень странно.

Разве в ядре не зопретили ZFS?

Мне не запретили, у меня 4.19 и zol 0.7.13

steeels ()

Я точно не помню, как vfs в этих ваших линуксах работает, но shared memory по идее должно мапиться на диск, плюс синхронная запись без отдельного slog. Я бы предложил протрейсить путь dtrace, но тебе придётся самому выбрать инструмент из доступных.

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

Эксперимент с записью fio в файл в /dev/shm дает скорость порядка 1.6гбс, но если этот файл превратить в блочный девайс через losetup, то скорость падает до 70мбс. Падение производительности в 20 раз в этом случае тоже выглядит подозрительно и думается, что затык где-то в софте.
Вот эксперимент, где я в качестве отдельного slog прицепляю ssd, пускай и паршивенький:

me@moon:/test-pool$ sudo zpool status test-pool
  pool: test-pool
 state: ONLINE
  scan: none requested
config:

        NAME                                           STATE     READ WRITE CKSUM
        test-pool                                      ONLINE       0     0     0
          raidz1-0                                     ONLINE       0     0     0
            /dev/shm/disk1.img                         ONLINE       0     0     0
            /dev/shm/disk2.img                         ONLINE       0     0     0
            /dev/shm/disk3.img                         ONLINE       0     0     0
        logs
          ata-KINGSTON_SV300S37A120G_50026B724C04F508  ONLINE       0     0     0

errors: No known data errors
me@moon:/test-pool$ sudo fio --filename=test --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=5G --runtime=300 && rm test
test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=4
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 5120MiB)
^Cbs: 1 (f=1): [W(1)][3.7%][w=14.0MiB/s][w=3828 IOPS][eta 04m:49s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=16344: Fri Jun 21 11:27:56 2019
  write: IOPS=3784, BW=14.8MiB/s (15.5MB/s)(164MiB/11121msec); 0 zone resets
    clat (usec): min=166, max=102365, avg=262.03, stdev=612.70
     lat (usec): min=166, max=102365, avg=262.32, stdev=612.70
    clat percentiles (usec):
     |  1.00th=[  212],  5.00th=[  221], 10.00th=[  225], 20.00th=[  231],
     | 30.00th=[  237], 40.00th=[  241], 50.00th=[  245], 60.00th=[  251],
     | 70.00th=[  258], 80.00th=[  265], 90.00th=[  281], 95.00th=[  302],
     | 99.00th=[  359], 99.50th=[  420], 99.90th=[ 2212], 99.95th=[ 2704],
     | 99.99th=[19792]
   bw (  KiB/s): min=12464, max=16104, per=99.94%, avg=15129.86, stdev=998.03, samples=22
   iops        : min= 3116, max= 4026, avg=3782.45, stdev=249.52, samples=22
  lat (usec)   : 250=59.47%, 500=40.15%, 750=0.05%, 1000=0.02%
  lat (msec)   : 2=0.03%, 4=0.25%, 10=0.01%, 20=0.01%, 50=0.01%
  lat (msec)   : 250=0.01%
  cpu          : usr=1.11%, sys=27.23%, ctx=126338, majf=0, minf=24
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,42092,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=4

Run status group 0 (all jobs):
  WRITE: bw=14.8MiB/s (15.5MB/s), 14.8MiB/s-14.8MiB/s (15.5MB/s-15.5MB/s), io=164MiB (172MB), run=11121-11121msec

steeels ()
Ответ на: комментарий от Dimez

zfs get recordsize покажет, что он по-умолчанию 128k. А fio тестируется с 4k?

Да, дефолтный рекордсайз 128к, фио тестирует с 4к в данном запуске.
Я продолжаю апеллировать к этой статье(https://martin.heiland.io/2018/02/23/zfs-tuning/) или услышать доводы, почему это невозможно. Да, автор не указал всех настроек zfs.
Вариант с slog на отдельном ssd: Опять медленная скорость работы ZFS (комментарий)
Вариант с slog в раме:

me@moon:/test-pool$ sudo zpool status test-pool
  pool: test-pool
 state: ONLINE
  scan: none requested
config:

        NAME                    STATE     READ WRITE CKSUM
        test-pool               ONLINE       0     0     0
          raidz1-0              ONLINE       0     0     0
            /dev/shm/disk1.img  ONLINE       0     0     0
            /dev/shm/disk2.img  ONLINE       0     0     0
            /dev/shm/disk3.img  ONLINE       0     0     0
        logs
          /dev/shm/slog.img     ONLINE       0     0     0

errors: No known data errors
me@moon:/test-pool$ sudo fio --filename=test --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=5G --runtime=300 && rm test
test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=4
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 5120MiB)
^Cbs: 1 (f=1): [W(1)][6.1%][w=32.9MiB/s][w=8422 IOPS][eta 02m:33s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=20317: Fri Jun 21 11:33:03 2019
  write: IOPS=8077, BW=31.6MiB/s (33.1MB/s)(332MiB/10519msec); 0 zone resets
    clat (usec): min=71, max=48559, avg=122.20, stdev=340.15
     lat (usec): min=71, max=48559, avg=122.45, stdev=340.16
    clat percentiles (usec):
     |  1.00th=[   93],  5.00th=[   99], 10.00th=[  102], 20.00th=[  106],
     | 30.00th=[  110], 40.00th=[  112], 50.00th=[  115], 60.00th=[  119],
     | 70.00th=[  123], 80.00th=[  128], 90.00th=[  139], 95.00th=[  155],
     | 99.00th=[  196], 99.50th=[  217], 99.90th=[  363], 99.95th=[  578],
     | 99.99th=[ 2376]
   bw (  KiB/s): min=29544, max=34456, per=100.00%, avg=32313.81, stdev=1585.65, samples=21
   iops        : min= 7386, max= 8614, avg=8078.43, stdev=396.40, samples=21
  lat (usec)   : 100=6.31%, 250=93.41%, 500=0.22%, 750=0.04%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=1.79%, sys=43.91%, ctx=85084, majf=0, minf=24
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,84964,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=4

Run status group 0 (all jobs):
  WRITE: bw=31.6MiB/s (33.1MB/s), 31.6MiB/s-31.6MiB/s (33.1MB/s-33.1MB/s), io=332MiB (348MB), run=10519-10519msec

steeels ()
Ответ на: комментарий от Dimez

zfs get recordsize покажет, что он по-умолчанию 128k. А fio тестируется с 4k?

Вот запуск с рекородсайз в 4к, разницы, вроде, незаметно:

me@moon:/test-pool$ sudo zfs get recordsize test-pool
NAME       PROPERTY    VALUE    SOURCE
test-pool  recordsize  4K       local
me@moon:/test-pool$ sudo fio --filename=test --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=5G --runtime=300 && rm test
test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=4
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 5120MiB)
^Cbs: 1 (f=1): [W(1)][4.4%][w=25.6MiB/s][w=6561 IOPS][eta 02m:52s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=28784: Fri Jun 21 11:35:01 2019
  write: IOPS=7432, BW=29.0MiB/s (30.4MB/s)(252MiB/8680msec); 0 zone resets
    clat (usec): min=78, max=66697, avg=132.96, stdev=389.12
     lat (usec): min=78, max=66698, avg=133.24, stdev=389.18
    clat percentiles (usec):
     |  1.00th=[  103],  5.00th=[  110], 10.00th=[  113], 20.00th=[  115],
     | 30.00th=[  117], 40.00th=[  119], 50.00th=[  122], 60.00th=[  125],
     | 70.00th=[  128], 80.00th=[  133], 90.00th=[  139], 95.00th=[  147],
     | 99.00th=[  208], 99.50th=[  351], 99.90th=[ 1549], 99.95th=[ 3490],
     | 99.99th=[13566]
   bw (  KiB/s): min=20032, max=32624, per=99.83%, avg=29676.35, stdev=4082.36, samples=17
   iops        : min= 5008, max= 8156, avg=7419.00, stdev=1020.61, samples=17
  lat (usec)   : 100=0.57%, 250=98.69%, 500=0.37%, 750=0.13%, 1000=0.07%
  lat (msec)   : 2=0.09%, 4=0.04%, 10=0.02%, 20=0.01%, 50=0.01%
  lat (msec)   : 100=0.01%
  cpu          : usr=1.56%, sys=42.16%, ctx=65265, majf=0, minf=19
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,64511,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=4

Run status group 0 (all jobs):
  WRITE: bw=29.0MiB/s (30.4MB/s), 29.0MiB/s-29.0MiB/s (30.4MB/s-30.4MB/s), io=252MiB (264MB), run=8680-8680msec

steeels ()
Ответ на: комментарий от imul

Т.е. выходит, что количество иопсов в раму держится на уровне 4.7-6000? У меня количество иопсов схожее.
Но это, опять же, странно звучит: https://ru.wikipedia.org/wiki/RAM-диск, https://www.snia.org/sites/default/orig/DSI2015/presentations/SolidState/Eden...
Ок, тут, конечно, не совсем рамдиск, но интуитивно разница не должна быть в 2-3 порядка.

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

Да, что-то я протупил момент с дд, похмелье оно такое. Тогда 4к подозреваемый, чем меньше размер блока, тем ниже пропускная способность. но почему в памяти такая лажа происходит, тут тебе только трейс поможет, у меня сейчас ни компа под рукой, ни желания туда логиниться.

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

чем меньше размер блока, тем ниже пропускная способность

Поправь меня, если я ошибаюсь: у железки есть ограничение на скорость записи в нее и на количество иопсов. Если утрировать, то скорость записи = иопс * размер блока.
Уменьшая размер блока, мы можем найти максимальное количество иопсов и заметить. После чего, увеличивая размер блока и следя за тем, чтобы иопсы оставались на уровне максимальных, можно найти максимальную скорость записи в железку. Сори за поток мысли.

Тогда 4к подозреваемый

Я попробовал на zfs выставить рекордсайз в 4к, чтобы уменьшить количество накладных расходов, но ситуацию это не изменило.
Буду читать про dtrace

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

После чего, увеличивая размер блока и следя за тем, чтобы иопсы оставались на уровне максимальных

Не будут иопсы на уровне максимальных. Они будут падать. Просто где-то будет перегиб на графике. Перегиб по идее должен соответствовать максимуму пропускной способности.

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

В общем ход мыслей правильный. Главные параметры диска - это iops и latency, от них всё пляшет.

Я попробовал на zfs выставить рекордсайз в 4к

Так ты у fio 128к выстави и у зфс в зад верни значение, у тебя же не база какая.

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

С 128к стало на порядок лучше, да. Но как тогда(я уже писал об этом где-то выше) у этого дядьки(https://martin.heiland.io/2018/02/23/zfs-tuning/) на реальных железках числа получаются куда больше, чем в моем случае с рамой?

me@moon:/test-pool$ sudo zfs set recordsize=128k test-pool
me@moon:/test-pool$ sudo fio --filename=test --sync=1 --rw=write --bs=128k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=5G --runtime=300 && rm test
test: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=psync, iodepth=4
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 5120MiB)
^Cbs: 1 (f=1): [W(1)][47.1%][w=303MiB/s][w=2421 IOPS][eta 00m:09s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=13750: Fri Jun 21 11:59:33 2019
  write: IOPS=2444, BW=306MiB/s (320MB/s)(2408MiB/7880msec); 0 zone resets
    clat (usec): min=217, max=14558, avg=399.27, stdev=407.73
     lat (usec): min=222, max=14575, avg=406.77, stdev=409.15
    clat percentiles (usec):
     |  1.00th=[  247],  5.00th=[  281], 10.00th=[  293], 20.00th=[  306],
     | 30.00th=[  314], 40.00th=[  322], 50.00th=[  334], 60.00th=[  343],
     | 70.00th=[  355], 80.00th=[  379], 90.00th=[  510], 95.00th=[  709],
     | 99.00th=[ 1352], 99.50th=[ 1860], 99.90th=[ 6587], 99.95th=[ 9503],
     | 99.99th=[14222]
   bw (  KiB/s): min=291584, max=349952, per=100.00%, avg=313377.47, stdev=17941.09, samples=15
   iops        : min= 2278, max= 2734, avg=2448.20, stdev=140.11, samples=15
  lat (usec)   : 250=1.27%, 500=88.23%, 750=6.14%, 1000=2.29%
  lat (msec)   : 2=1.62%, 4=0.21%, 10=0.19%, 20=0.04%
  cpu          : usr=2.68%, sys=43.99%, ctx=20372, majf=0, minf=49
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,19265,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=4

Run status group 0 (all jobs):
  WRITE: bw=306MiB/s (320MB/s), 306MiB/s-306MiB/s (320MB/s-320MB/s), io=2408MiB (2525MB), run=7880-7880mse

steeels ()
Ответ на: комментарий от bdfy

Так на железке все еще хуже.
Я специально пошел тестировать сетап в раме, тк предполагаю, что она всяко быстрее моих дисков и ссд.
Вот запуск на реальной железке:

me@moon:/tank$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 6h21m with 0 errors on Sun Jun  9 06:45:09 2019
config:

        NAME                                           STATE     READ WRITE CKSUM
        tank                                           ONLINE       0     0     0
          raidz1-0                                     ONLINE       0     0     0
            ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K0FU2HCS   ONLINE       0     0     0
            ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K3PH8N9X   ONLINE       0     0     0
            ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K5SZALZ6   ONLINE       0     0     0
        logs
          ata-KINGSTON_SV300S37A120G_50026B724C04F508  ONLINE       0     0     0

errors: No known data errors
me@moon:/tank$ sudo fio --filename=test --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=4 --group_reporting --name=test --filesize=10G --runtime=300 && rm test
test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=4
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 10240MiB)
^Cbs: 1 (f=1): [W(1)][3.0%][w=15.1MiB/s][w=3870 IOPS][eta 04m:52s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=11688: Fri Jun 21 12:18:46 2019
  write: IOPS=3753, BW=14.7MiB/s (15.4MB/s)(130MiB/8843msec); 0 zone resets
    clat (usec): min=189, max=290680, avg=264.31, stdev=1623.22
     lat (usec): min=189, max=290681, avg=264.60, stdev=1623.23
    clat percentiles (usec):
     |  1.00th=[  208],  5.00th=[  217], 10.00th=[  221], 20.00th=[  227],
     | 30.00th=[  233], 40.00th=[  237], 50.00th=[  243], 60.00th=[  247],
     | 70.00th=[  253], 80.00th=[  262], 90.00th=[  277], 95.00th=[  302],
     | 99.00th=[  359], 99.50th=[  420], 99.90th=[ 2180], 99.95th=[ 2573],
     | 99.99th=[22152]
   bw (  KiB/s): min= 6107, max=16312, per=100.00%, avg=15062.76, stdev=2331.50, samples=17
   iops        : min= 1526, max= 4078, avg=3765.65, stdev=583.04, samples=17
  lat (usec)   : 250=64.31%, 500=35.33%, 750=0.03%, 1000=0.03%
  lat (msec)   : 2=0.02%, 4=0.25%, 10=0.01%, 50=0.01%, 500=0.01%
  cpu          : usr=1.04%, sys=27.36%, ctx=99633, majf=0, minf=19
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.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.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,33193,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=4

Run status group 0 (all jobs):
  WRITE: bw=14.7MiB/s (15.4MB/s), 14.7MiB/s-14.7MiB/s (15.4MB/s-15.4MB/s), io=130MiB (136MB), run=8843-8843msec

steeels ()
Ответ на: комментарий от Dimez

Пока не очень представляю, как правильно собрать статистику для нумы, но вот выхлоп нумастата:

me@moon:/tank$ sudo numastat  -v

Per-node numastat info (in MBs):
                          Node 0          Node 1           Total
                 --------------- --------------- ---------------
Numa_Hit                66306.92        32501.25        98808.17
Numa_Miss                   0.00          975.73          975.73
Numa_Foreign              975.73            0.00          975.73
Interleave_Hit            106.22          106.12          212.34
Local_Node              66303.31        32377.83        98681.14
Other_Node                  3.61         1099.15         1102.76

Имхо, чиселки не выглядят устрашающе, чтобы думать на нуму.

steeels ()
Ответ на: комментарий от Dimez

dd при создании файлов показывает ту же скорость.
fio при bs=4k показывает ту же скорость.
А при 128k разница почти два раза по нескольким прогонам.
Непонятно.

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

Потому что это вечная проблема с ZFS.

Вечная проблема, что реализация работы с файлами (которую не рекомендуют использовать в проде, ибо она для тестов) тормозит? Ты бы хоть документацию дочитал, что ли.

скорости в несколько раз выше даже на шпинделях

на шпинделях

И ты продолжаешь жаловаться, что у тебя тормозит на файлах? Даже смешно.

zol 0.7.13

В любом случае тебе даже обновление с файлами не поможет.

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

Вечная проблема, что реализация работы с файлами (которую не рекомендуют использовать в проде, ибо она для тестов) тормозит?

Почитай стартовый пост. Я и говорю, что использую такой сетап для тестов.

И ты продолжаешь жаловаться, что у тебя тормозит на файлах? Даже смешно.

Почитай, пожалуйста, вот этот коммент: Опять медленная скорость работы ZFS (комментарий) я замерял скорость на реальной дисковой подсистеме. Результат, как видишь, ощутимо хуже.
Мне кажется, что проблема, в итоге не в zfs, а где-то в линуксе, тк скорость записи через fio в файл и в блочное устройство из этого файла различается в 20 раз.

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

Я попробовал на zfs выставить рекордсайз в 4к, чтобы уменьшить количество накладных расходов, но ситуацию это не изменило.

Мало выставить рекордсайз в 4к, надо еще удалить файл, в который пишешь.

anonymous ()
Ответ на: комментарий от steeels

Я и говорю, что использую такой сетап для тестов.

Это не для тестирования скорости сделано.

я замерял скорость на реальной дисковой подсистеме

Harliff тоже, и у него та же проблема. И он, как и ты, использовал fio для замеров. Такой просадки в боевых условиях я никогда не встречал.

Мне кажется, что проблема, в итоге не в zfs, а где-то в линуксе

скорость записи через fio

А может даже и просто в fio. Но выяснять я не хочу — у меня просто нет свободных дисков для тестирования.

В общем, соболезную оставшимся жрать этот кактус. Передаю привет из уютной боевой FreeBSD. :3

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

Всем привет!

реализация работы с файлами (которую не рекомендуют использовать в проде, ибо она для тестов)

А можно ссылку?

Хотя у меня схожий опыт - файловая шара с zfs тормозила (внезапные фризы, так что пользователи их замечали и жаловались), переделал на xfs over zvol - стало лучше. Оптимизацией настроек я там не занимался (кроме ashift). Версии - которые в proxmox 4.4 были (сейчас не удобно смотреть).

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

Но выяснять я не хочу — у меня просто нет свободных дисков для тестирования.

Готов позапускать тесты на железе в начале след. недели и выложить результаты. Пишите!

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

Такой просадки в боевых условиях я никогда не встречал.

В боевых условиях загрузка дисковой подсистемы не 100%, это понятно. Бенчмарки тут нужны, что бы понимать, где «потолок» (в который потом упрутся реальные приложения, когда нагрузка на продакшен возрастёт).

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

А можно ссылку?

Так это даже в zpool(8) написано:

file
A regular file. The use of files as a backing store is strongly discouraged. It is designed primarily for experimental purposes, as the fault tolerance of a file is only as good the file system of which it is a part. A file must be specified by a full path.

В боевых условиях загрузка дисковой подсистемы не 100%, это понятно.

Ну не 100%, но до 50% бывает.

Бенчмарки тут нужны, что бы понимать, где «потолок» (в который потом упрутся реальные приложения, когда нагрузка на продакшен возрастёт).

Бенчи нужны в первую очередь для выявления bottle neck.

Скажите, во freebsd результаты намного лучше?

Я бенчей не проводил, у меня свободных дисков нет. Даже данные сослать некуда, чтобы освободить один из имеющихся.

Сейчас во FreeBSD 12.0-RELEASE (и предыдущих релизах) используется код из, если не ошибаюсь, OpenSolaris, но уже в FreeBSD 13.0-CURRENT есть (экспериментальная) возможность установить zfsonlinux из портов или пакетов, но я не тыкал — некуда ставить, а на виртуальных дисках обкатывать не вижу смысла.

mord0d ()