у них 7.5 реальной

MTU 1500 ?

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

и там и там

DA патчи

mellanox

не. я спать - в сибири 02 часа. потестируйте отдачу ссд, на том станет ясно — это ZFS или передача наружу такое творит

mellanox

ты не далеко

Или, вернее, под какой ОС?

Омск

а. там на линуксе драйвера из дистра иногда шалят...

вощем потестируйте таргет, на том станет яснее, куды копать. Ну, можно ещё локально ZFS нагрузить fio

> сколько показывает fio при потоковой записи на датасет под пг? sudo fio --name=random-write --ioengine=libaio --rw=readwrite --bs=8k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 Run status group 0 (all jobs): READ: io=17255MB, aggrb=294178KB/s, minb=294178KB/s, maxb=294178KB/s, mint=60063msec, maxt=60063msec WRITE: io=17235MB, aggrb=293837KB/s, minb=293837KB/s, maxb=293837KB/s, mint=60063msec, maxt=60063msec甀 sudo fio --name=random-write --ioengine=libaio --rw=readwrite --bs=8k --numjobs=4 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 Run status group 0 (all jobs): READ: io=34592MB, aggrb=503800KB/s, minb=111323KB/s, maxb=140870KB/s, mint=70310msec, maxt=70310msec WRITE: io=34547MB, aggrb=503146KB/s, minb=111169KB/s, maxb=140662KB/s, mint=70310msec, maxt=70310msec sudo fio --name=random-write --ioengine=libaio --rw=readwrite --bs=128k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 Run status group 0 (all jobs): READ: io=22479MB, aggrb=369939KB/s, minb=369939KB/s, maxb=369939KB/s, mint=62221msec, maxt=62221msec WRITE: io=22578MB, aggrb=371568KB/s, minb=371568KB/s, maxb=371568KB/s, mint=62221msec, maxt=62221msec缀 sudo fio --name=random-write --ioengine=libaio --rw=readwrite --bs=128k --numjobs=4 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 Run status group 0 (all jobs): READ: io=44583MB, aggrb=709609KB/s, minb=152539KB/s, maxb=208948KB/s, mint=64335msec, maxt=64335msec WRITE: io=44751MB, aggrb=712283KB/s, minb=152999KB/s, maxb=209785KB/s, mint=64335msec, maxt=64335msec pg_test_fsync -s 60 O_DIRECT supported on this platform for open_datasync and open_sync. Compare file sync methods using one 8kB write: (in wal_sync_method preference order, except fdatasync is Linux's default) open_datasync n/a* fdatasync 921.008 ops/sec 1086 usecs/op fsync 884.796 ops/sec 1130 usecs/op fsync_writethrough n/a open_sync n/a* * This file system and its mount options do not support direct I/O, e.g. ext4 in journaled mode. Compare file sync methods using two 8kB writes: (in wal_sync_method preference order, except fdatasync is Linux's default) open_datasync n/a* fdatasync 925.470 ops/sec 1081 usecs/op fsync 936.285 ops/sec 1068 usecs/op fsync_writethrough n/a open_sync n/a* * This file system and its mount options do not support direct I/O, e.g. ext4 in journaled mode. Compare open_sync with different write sizes: (This is designed to compare the cost of writing 16kB in different write open_sync sizes.) 1 * 16kB open_sync write n/a* 2 * 8kB open_sync writes n/a* 4 * 4kB open_sync writes n/a* 8 * 2kB open_sync writes n/a* 16 * 1kB open_sync writes n/a* Test if fsync on non-write file descriptor is honored: (If the times are similar, fsync() can sync data written on a different descriptor.) write, fsync, close 897.440 ops/sec 1114 usecs/op write, close, fsync 926.619 ops/sec 1079 usecs/op Non-sync'ed 8kB writes: write 98781.155 ops/sec 10 usecs/op

это не randrw, а просто readwrite = "Sequential mixed reads and writes". Вы предполагаете что у ПГ именно такой профиль записи? --rw=randrw - это тестирование случайного чтения/запись. тестировать с bs=128k смысла не вижу, у вас PG всё равно будет читать/писать блоками по 8k. Может конечно вы что-то и захватите за счёт read ahead, но большого выигрыша не будет, скорее будут потери. какой размер ashift у пула? ещё выведите инфу про датасеты: zfs list -o type,name,used,avail,compressratio,logbias,sync,atime,primarycache,compress,recordsize

это не randrw, а просто readwrite = "Sequential mixed reads and writes". Вы предполагаете что у ПГ именно такой профиль записи? --rw=randrw - это тестирование случайного чтения/запись. тестировать с bs=128k смысла не вижу, у вас PG всё равно будет читать/писать блоками по 8k. Может конечно вы что-то и захватите за счёт read ahead, но большого выигрыша не будет, скорее будут потери. какой размер ashift у пула? ещё выведите инфу про датасеты: zfs list -o type,name,used,avail,compressratio,logbias,sync,atime,primarycache,compress,recordsize

у вас sync включен по факту logbias сделайте latency я бы recsize больше 16к не делал ну и при накатывании логов последовательным может быть скорее чтение валов, чем запись в СУБД. А в CGP случайные чтение/запись могут иметь другие показатели чем последовательные. сильно другие

переключение синка - не дает никакго эффекта, logbias=latency - делает хуже. ждем именно записи и именно в файлы данных (делали замеры с помощью psn от Подера)

тогда остаётся только предположение что гугловские сетевые диски не подходят в качестве vdev для zfs.

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

вряд ли вам поддержка поможет. В лучшем случае предложат бареметалл от гугла за невменяемые деньги. в полном отчёте fio посмотрите на lat (clat/slat). Может с этим связано.

а что именно смотреть, подскажите пожалуйста, вот например для 8к write: io=17235MB, bw=293838KB/s, iops=36729, runt= 60063msec slat (usec): min=6, max=6356, avg=11.73, stdev=20.34 clat (usec): min=0, max=431, avg= 0.94, stdev= 1.14 lat (usec): min=7, max=6363, avg=12.80, stdev=20.53 clat percentiles (usec): | 1.00th=[ 0], 5.00th=[ 0], 10.00th=[ 0], 20.00th=[ 1], | 30.00th=[ 1], 40.00th=[ 1], 50.00th=[ 1], 60.00th=[ 1], | 70.00th=[ 1], 80.00th=[ 1], 90.00th=[ 1], 95.00th=[ 1], | 99.00th=[ 2], 99.50th=[ 2], 99.90th=[ 8], 99.95th=[ 16], | 99.99th=[ 35] bw (KB /s): min=320704, max=417392, per=100.00%, avg=344608.32, stdev=16251.80 lat (usec) : 2=96.00%, 4=3.76%, 10=0.17%, 20=0.05%, 50=0.02% lat (usec) : 100=0.01%, 250=0.01%, 500=0.01% для 128к write: io=22578MB, bw=371568KB/s, iops=2902, runt= 62221msec slat (usec): min=36, max=104252, avg=92.99, stdev=542.79 clat (usec): min=0, max=742, avg= 1.40, stdev= 2.38 lat (usec): min=38, max=104260, avg=94.74, stdev=542.91 clat percentiles (usec): | 1.00th=[ 1], 5.00th=[ 1], 10.00th=[ 1], 20.00th=[ 1], | 30.00th=[ 1], 40.00th=[ 1], 50.00th=[ 1], 60.00th=[ 1], | 70.00th=[ 2], 80.00th=[ 2], 90.00th=[ 2], 95.00th=[ 2], | 99.00th=[ 3], 99.50th=[ 4], 99.90th=[ 15], 99.95th=[ 21], | 99.99th=[ 54] bw (KB /s): min=371968, max=1009920, per=100.00%, avg=646113.08, stdev=136045.23 lat (usec) : 2=70.16%, 4=29.17%, 10=0.50%, 20=0.11%, 50=0.05% lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%

https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0

2.0 зарелизили? или это пока на уровне исходников для самосбора?

релиз то релиз, но пока предсобранных пакетов нет.. и draid как я понял не включили в этот релиз.. According to Mark Maybee presentation, the present lead architect for the dRAID, the feature will miss out in the OpenZFS 2.0 release but will be in coming 2.x release after that.

Если кому интересны подкасты - поговорили о zfs, её внутренностях, проекте openZFS https://sdcast.ksdaemon.ru/2020/09/sdcast-122/

Выпустили статью по мотивам подкаста https://habr.com/ru/company/mailru/blog/529516/ Рассказал про основы, немного про архитектуру, и что творится в проекте

Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. ))))

вы хотите от сетевых дисков с негарантированными показателями получить характеристики, которые даёт железо. Гугл может вам в любой момент "придушить" дисковый ввод-вывод согласно тарифного плана (размера диска/кол-во ЦПУ). Ну это не тот кейс, где используют ZFS

гугл гарантирует 25000 IOPS и 1200MiB для данных дисков (при нашем размере и кол-во ЦПУ) - если мы упираемся в какие-то показатели дисков - то хотелось бы понять как это увидеть, чтобы можно было в том числе поговорить с поддержкой, если ZFS чего-то не хватает в физических характеристиках - то как увидеть (какими тулзами)?

😁 жизнь она такая, разносторонняя

zpool iostat, там есть разные опции для определения латенси, размеров блока, очереди. p.s. через сравнение с показателями пула, чьи характеристики устраивают более чем

гугл гарантирует 25000 IOPS и 1200MiB для данных дисков (при нашем размере и кол-во ЦПУ) - если мы упираемся в какие-то показатели дисков - то хотелось бы понять как это увидеть, чтобы можно было в том числе поговорить с поддержкой, если ZFS чего-то не хватает в физических характеристиках - то как увидеть (какими тулзами)?

а если нет, такого пула - с котором можно сравнить. Ситуация следующая: из всех установок скриптововй обвязки, которая использует zfs, установка на GCP самая нагруженная и это единственный пока кейс где скорости zfs на запись не хватает. и хочется понять это ограничения самого zfs, каких-то настроек (пула, или самого модуля) или чего-то другого, т.к. на первый и второй взгляд насыщения каких-то системных ресурсов не наступает.

а вы же через fio проверяли что gcp эти цифры в реальности показывает? На всякий спрошу

вряд ли я смогу сказать какие должны быть эталонные показатели в zpool iostat. Нагрузка разная у всех, железо тоже разное бывает.

нет не показывает, показывает сильно ниже и это вопрос почему - проблемы диска или проблема zfs (при этом fio показывает показатели выше чем posgtres)

даже если показатели ниже условных эталонных - то как понять почему?

погодите, я имею в виду запустить fio на сыром диске, БЕЗ zfs

ок, попробуем fio на сыром девайсе, спасибо

Выпустили статью по мотивам подкаста https://habr.com/ru/company/mailru/blog/529516/ Рассказал про основы, немного про архитектуру, и что творится в проекте

Спасибо за труд!

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

За публикацию спасибо, познавательно! Я всё жду статью из reply сообщения :))

👍 а какой из реплаев, про сравнение?

Реплай про восстановление проблемных пулов )