« Rev
@ru_zfs   185
Fwd »


Dmitry
еще раз спасибо за вчерашнюю консультацию. прогнали вчера тесты на рандомную запись на сыром девайсе, на созданному пуле выключенной компрессией с разными значениями ashift, recordsize, и на страйпе из 3х дисков по 3.5ТБ. Сырой диск выдал половину от заявленной пропускной способности, но все равно очень хорошие показатели sudo fio --name=random-write --ioengine=libaio --rw=randwrite --bs=8k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=/dev/disk/by-id/google-data-disk-2 random-write: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=libaio, iodepth=1 fio-3.16 Starting 1 process Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=1089100: Thu Dec 3 20:39:20 2020 write: IOPS=66.9k, BW=522MiB/s (548MB/s)(32.0GiB/62716msec); 0 zone resets slat (usec): min=3, max=848, avg= 5.33, stdev= 1.89 clat (nsec): min=624, max=511836, avg=748.91, stdev=432.70 lat (usec): min=4, max=850, avg= 6.18, stdev= 1.97 clat percentiles (nsec): | 1.00th=[ 708], 5.00th=[ 716], 10.00th=[ 716], 20.00th=[ 724], | 30.00th=[ 724], 40.00th=[ 732], 50.00th=[ 732], 60.00th=[ 740], | 70.00th=[ 740], 80.00th=[ 748], 90.00th=[ 764], 95.00th=[ 772], | 99.00th=[ 868], 99.50th=[ 948], 99.90th=[ 5280], 99.95th=[ 6944], | 99.99th=[15936] bw ( MiB/s): min= 126, max= 1214, per=100.00%, avg=1039.92, stdev=308.81, samples=63 iops : min=16134, max=155470, avg=133109.43, stdev=39527.71, samples=63 lat (nsec) : 750=79.91%, 1000=19.71% lat (usec) : 2=0.23%, 4=0.01%, 10=0.10%, 20=0.03%, 50=0.01% lat (usec) : 100=0.01%, 750=0.01% cpu : usr=10.11%, sys=58.80%, ctx=2879, majf=0, minf=10 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,4194305,0,1 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=522MiB/s (548MB/s), 522MiB/s-522MiB/s (548MB/s-548MB/s), io=32.0GiB (34.4GB), run=62716-62716msec
Dmitry
фио на созданный пул уже дало в половину меньше # sudo fio --name=random-write --ioengine=libaio --rw=randwrite --bs=8k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=/var/lib/test/file random-write: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=libaio, iodepth=1 fio-3.16 Starting 1 process random-write: Laying out IO file (1 file / 4096MiB) Jobs: 1 (f=1): [F(1)][100.0%][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=1089685: Thu Dec 3 20:47:36 2020 write: IOPS=28.2k, BW=221MiB/s (231MB/s)(13.5GiB/62540msec); 0 zone resets slat (usec): min=8, max=108253, avg=31.04, stdev=258.97 clat (nsec): min=797, max=410860, avg=1326.05, stdev=1666.95 lat (usec): min=9, max=108266, avg=32.70, stdev=259.05 clat percentiles (nsec): | 1.00th=[ 868], 5.00th=[ 892], 10.00th=[ 916], 20.00th=[ 972], | 30.00th=[ 1020], 40.00th=[ 1064], 50.00th=[ 1112], 60.00th=[ 1224], | 70.00th=[ 1400], 80.00th=[ 1576], 90.00th=[ 1784], 95.00th=[ 1976], | 99.00th=[ 3088], 99.50th=[ 4448], 99.90th=[15424], 99.95th=[23680], | 99.99th=[62208] bw ( KiB/s): min=132560, max=333968, per=100.00%, avg=235722.08, stdev=42612.02, samples=119 iops : min=16570, max=41746, avg=29465.22, stdev=5326.54, samples=119 lat (nsec) : 1000=25.87% lat (usec) : 2=69.68%, 4=3.86%, 10=0.42%, 20=0.09%, 50=0.06% lat (usec) : 100=0.01%, 250=0.01%, 500=0.01% cpu : usr=9.48%, sys=80.73%, ctx=36118, majf=0, minf=10 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,1766314,0,1 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=221MiB/s (231MB/s), 221MiB/s-221MiB/s (231MB/s-231MB/s), io=13.5GiB (14.5GB), run=62540-62540msec
Dmitry
страйп ничего не дал # sudo zpool create -f -O compression=off -O atime=off -O recordsize=8k -O logbias=throughput -O xattr=sa -o ashift=12 -m /var/lib/test test /dev/disk/by-id/google-data-disk-31 /dev/disk/by-id/google-disk-32 /dev/disk/by-id/google-data-disk-33 # sudo fio --name=random-write --ioengine=libaio --rw=randwrite --bs=8k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=/var/lib/test/file random-write: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=libaio, iodepth=1 fio-3.16 Starting 1 process random-write: Laying out IO file (1 file / 4096MiB) Jobs: 1 (f=1): [F(1)][100.0%][w=23.8MiB/s][w=3040 IOPS][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=2106293: Thu Dec 3 21:06:22 2020 write: IOPS=39.0k, BW=305MiB/s (320MB/s)(18.2GiB/61191msec); 0 zone resets slat (usec): min=9, max=22532, avg=22.76, stdev=57.36 clat (nsec): min=725, max=7129.2k, avg=1202.51, stdev=8120.37 lat (usec): min=9, max=22541, avg=24.19, stdev=58.45 clat percentiles (nsec): | 1.00th=[ 932], 5.00th=[ 964], 10.00th=[ 988], 20.00th=[ 1004], | 30.00th=[ 1012], 40.00th=[ 1032], 50.00th=[ 1032], 60.00th=[ 1048], | 70.00th=[ 1080], 80.00th=[ 1256], 90.00th=[ 1592], 95.00th=[ 1768], | 99.00th=[ 2096], 99.50th=[ 2448], 99.90th=[15424], 99.95th=[16512], | 99.99th=[28288] bw ( KiB/s): min=140614, max=421872, per=100.00%, avg=318640.91, stdev=70243.46, samples=119 iops : min=17576, max=52734, avg=39830.11, stdev=8780.49, samples=119 lat (nsec) : 750=0.01%, 1000=17.41% lat (usec) : 2=80.97%, 4=1.29%, 10=0.18%, 20=0.12%, 50=0.02% lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 4=0.01%, 10=0.01% cpu : usr=10.03%, sys=85.34%, ctx=3598, majf=0, minf=12 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,2389346,0,1 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=305MiB/s (320MB/s), 305MiB/s-305MiB/s (320MB/s-320MB/s), io=18.2GiB (19.6GB), run=61191-61191msec
Сергей
еще раз спасибо за вчерашнюю консультацию. прогнали вчера тесты на рандомную запись на сыром девайсе, на созданному пуле выключенной компрессией с разными значениями ashift, recordsize, и на страйпе из 3х дисков по 3.5ТБ. Сырой диск выдал половину от заявленной пропускной способности, но все равно очень хорошие показатели sudo fio --name=random-write --ioengine=libaio --rw=randwrite --bs=8k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=/dev/disk/by-id/google-data-disk-2 random-write: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=libaio, iodepth=1 fio-3.16 Starting 1 process Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=1089100: Thu Dec 3 20:39:20 2020 write: IOPS=66.9k, BW=522MiB/s (548MB/s)(32.0GiB/62716msec); 0 zone resets slat (usec): min=3, max=848, avg= 5.33, stdev= 1.89 clat (nsec): min=624, max=511836, avg=748.91, stdev=432.70 lat (usec): min=4, max=850, avg= 6.18, stdev= 1.97 clat percentiles (nsec): | 1.00th=[ 708], 5.00th=[ 716], 10.00th=[ 716], 20.00th=[ 724], | 30.00th=[ 724], 40.00th=[ 732], 50.00th=[ 732], 60.00th=[ 740], | 70.00th=[ 740], 80.00th=[ 748], 90.00th=[ 764], 95.00th=[ 772], | 99.00th=[ 868], 99.50th=[ 948], 99.90th=[ 5280], 99.95th=[ 6944], | 99.99th=[15936] bw ( MiB/s): min= 126, max= 1214, per=100.00%, avg=1039.92, stdev=308.81, samples=63 iops : min=16134, max=155470, avg=133109.43, stdev=39527.71, samples=63 lat (nsec) : 750=79.91%, 1000=19.71% lat (usec) : 2=0.23%, 4=0.01%, 10=0.10%, 20=0.03%, 50=0.01% lat (usec) : 100=0.01%, 750=0.01% cpu : usr=10.11%, sys=58.80%, ctx=2879, majf=0, minf=10 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,4194305,0,1 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=522MiB/s (548MB/s), 522MiB/s-522MiB/s (548MB/s-548MB/s), io=32.0GiB (34.4GB), run=62716-62716msec
Дмитрий, у вас тут только случайная запись. А где чтение? У вас ведь в ходе проигрывания валов и чтение и запись идут одновременно. Вам randrw нужен, и возможно не 50% на 50%, а с другим распределением
nikolay
» страйп ничего не дал - я может ошибаюсь, но на страйпе и iops и bw выросли?
Dmitry
в ожиданиях которые мы видим сейчас только ожидания записи, поэтому пока тестировали запись
George
страйп ничего не дал # sudo zpool create -f -O compression=off -O atime=off -O recordsize=8k -O logbias=throughput -O xattr=sa -o ashift=12 -m /var/lib/test test /dev/disk/by-id/google-data-disk-31 /dev/disk/by-id/google-disk-32 /dev/disk/by-id/google-data-disk-33 # sudo fio --name=random-write --ioengine=libaio --rw=randwrite --bs=8k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1 --filename=/var/lib/test/file random-write: (g=0): rw=randwrite, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=libaio, iodepth=1 fio-3.16 Starting 1 process random-write: Laying out IO file (1 file / 4096MiB) Jobs: 1 (f=1): [F(1)][100.0%][w=23.8MiB/s][w=3040 IOPS][eta 00m:00s] random-write: (groupid=0, jobs=1): err= 0: pid=2106293: Thu Dec 3 21:06:22 2020 write: IOPS=39.0k, BW=305MiB/s (320MB/s)(18.2GiB/61191msec); 0 zone resets slat (usec): min=9, max=22532, avg=22.76, stdev=57.36 clat (nsec): min=725, max=7129.2k, avg=1202.51, stdev=8120.37 lat (usec): min=9, max=22541, avg=24.19, stdev=58.45 clat percentiles (nsec): | 1.00th=[ 932], 5.00th=[ 964], 10.00th=[ 988], 20.00th=[ 1004], | 30.00th=[ 1012], 40.00th=[ 1032], 50.00th=[ 1032], 60.00th=[ 1048], | 70.00th=[ 1080], 80.00th=[ 1256], 90.00th=[ 1592], 95.00th=[ 1768], | 99.00th=[ 2096], 99.50th=[ 2448], 99.90th=[15424], 99.95th=[16512], | 99.99th=[28288] bw ( KiB/s): min=140614, max=421872, per=100.00%, avg=318640.91, stdev=70243.46, samples=119 iops : min=17576, max=52734, avg=39830.11, stdev=8780.49, samples=119 lat (nsec) : 750=0.01%, 1000=17.41% lat (usec) : 2=80.97%, 4=1.29%, 10=0.18%, 20=0.12%, 50=0.02% lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 4=0.01%, 10=0.01% cpu : usr=10.03%, sys=85.34%, ctx=3598, majf=0, minf=12 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,2389346,0,1 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: bw=305MiB/s (320MB/s), 305MiB/s-305MiB/s (320MB/s-320MB/s), io=18.2GiB (19.6GB), run=61191-61191msec
а на одном потоке разницы не будет, один поток прилетает на один vdev
George
sync=disabled не увидел, зато появился откуда то logbias=throughput. при отключённом синке не надо это менять, в общем то
Dmitry
а на одном потоке разницы не будет, один поток прилетает на один vdev
к сожалению постгрес во время наката логов и пишет в один поток и это проблема имхо
Dmitry
надо проверять
это из архитектуры постгреса и видно IOTOP
Dmitry
sync=disabled не увидел, зато появился откуда то logbias=throughput. при отключённом синке не надо это менять, в общем то
про синк правы, действительно упустил вчера в ночи (правда ни один из предыдущих тестов не давал разницы, но все равно надо добавить
Dmitry
ashift 0,12,13 не давал разницы
Dmitry
recordsize=4,8,32,128 - лучший результат на 8k
Dmitry
если тестировать постгрес отдельно от наката валов (создание индексов, удаление обхектов, копирование данных) то 128K показывает значительно лучше себя (время сокращается в разы, сжатие гораздо эффективнее), снапшоты также создаются быстрее
Dmitry
если нам вдруг хватит производительности на 8k, то придется как-то решать эти вопросы
Сергей
если тестировать постгрес отдельно от наката валов (создание индексов, удаление обхектов, копирование данных) то 128K показывает значительно лучше себя (время сокращается в разы, сжатие гораздо эффективнее), снапшоты также создаются быстрее
у ПГ размер страницы 8к, при рексайз 128к у вас будет сжатие БД отличное, но много лишних операций. Для OLTP нагрузки с небольшим объёмом записи - это снижает TPS. У вас на мастере кстати сжатие WAL включено?
Dmitry
у ПГ размер страницы 8к, при рексайз 128к у вас будет сжатие БД отличное, но много лишних операций. Для OLTP нагрузки с небольшим объёмом записи - это снижает TPS. У вас на мастере кстати сжатие WAL включено?
нужно еще раз перепроверить включено сжатие или нет (источник не по моим управлением). если хоть с каким-то вариантом настроек мы будем более-менее успевать за мастером, то будем предпринимать шаги по уменьшению объемов записи на мастере
Dmitry
200Mb которые выдавал фио хватает впритык если сравнивать с репликой которая работает с тем же мастером но на ext4
Aleksei
200Mb которые выдавал фио хватает впритык если сравнивать с репликой которая работает с тем же мастером но на ext4
заранее извиняюсь за бестактный вопрос: а если ext4 так хорошо работает, то зачем переезжать на ZFS?
Mikhail
заранее извиняюсь за бестактный вопрос: а если ext4 так хорошо работает, то зачем переезжать на ZFS?
клоны базы можно создавать за считанные секунды, бекапы в виде снепшотов ))))
Dmitry
Нужен функционал по созданию снапшотов, CoW
Mikhail
А какой слоник? 12?
Dmitry
А какой слоник? 12?
wal-g тёплый стендбай
Алексей
Всем чатом бьемся, просто нерешаемый кейс какой-то)
Mikhail
я про версию спросил. Тут ещё такой момент, что любая реплика рано или поздно станет мастером. И тюнить ZFS под recovery совсем верный подход ибо реплика всегда отдыхает по сравнению с мастером
Алексей
Совсем верный?
Dmitry
я про версию спросил. Тут ещё такой момент, что любая реплика рано или поздно станет мастером. И тюнить ZFS под recovery совсем верный подход ибо реплика всегда отдыхает по сравнению с мастером
Не так понял прошу прощения, версии 11. Эта реплика никого не станет мастером, для этого есть реплики на ext4, эта реплика станет донором клонов как вы верно предположили
Ivan
Нужен функционал по созданию снапшотов, CoW
а на lvm прям совсем плохо с этим ?
Dmitry
а на lvm прям совсем плохо с этим ?
Когда последний раз к этому возвращались не было сравнимого функционала по созданию клонов из снапшотов
Владимир
а на lvm прям совсем плохо с этим ?
снапшот ещё ладно, а если надо реплицировать состояние куда-то)
Dmitry
Всем чатом бьемся, просто нерешаемый кейс какой-то)
Думаю мне просто не хватает экспертизы в zfs чтобы правильно затенить или хотчбч понять где проблема, за этим и пришёл )
Владимир
но на сколько мне изветсно отстающая по реализации
Dmitry
в целом у lvm есть репликация
Может я не знаю просто как это сделать и вы подскажите. Нужен такой функционал снять снапшот текущего состояния, сделать из него клон и поимонтировать в новую точку. При этом размер этого клона определялся бы только кол-вом изменённых блоков
Mikhail
по постгре мне эта преза нравилась, увы в жизни не применял, но вещи по делу https://people.freebsd.org/~seanc/postgresql/scale15x-2017-postgresql_zfs_best_practices.pdf
вот статья от Sean как правильно приготовить zfs+pg. По ней всё сделано? Есть ещё опыт Dan Langille. хотя это всё из bsd мирка.
Dmitry
Да по ней все сделано
Mikhail
Это ответ был Дмитрию про экспертизу)
Mikhail
тогда по поводу pg - bgwriter как настроен? Это тоже важно для recovery.
Dmitry
Да по ней все сделано
В реальности эффекто не дало ни одна из идей
Mikhail
У вас рекавери может идти волнами из-за состояния буфера в shmem.
Mikhail
к примеру когда bgwriter будет опаздывать, то startup-у придётся делать его работу и тем самым создаётся обратное давление накату.
Dmitry
Настройки идентичны репликам на ext4
Посмотрю в эту сторону спасибо
Mikhail
в случаи ZFS они должны быть чуточку агрессивнее IMHO.
Dmitry
Доступ к серверу появится чуть позже, подскажите плз какие именно параметры показать?
Mikhail
https://postgrespro.ru/docs/postgrespro/11/runtime-config-resource#RUNTIME-CONFIG-RESOURCE-BACKGROUND-WRITER
Dmitry
Бграйтер пробовали крутить настройки эффекта видно не было
Dmitry
Попробуем ещё раз
Dmitry
Fsync тоже не давал никакого эффекта почему-то
Mikhail
Fsync тоже не давал никакого эффекта почему-то
fsync может быть и дешевым. в клаудах везде SDS-ы которые fsync-и интересно обрабатывают. по gcp не могу сказать, но в aws/oracle cloud разное поведение от fsync-а.
Mikhail
в aws - лучше. в oracle cloud - без изменений.
Dmitry
да тесты в aws (для удешевления процесса) давали совершенно другое поведение пришлось перейти к тестам на реальной инфре
Dmitry
до определнного момента увеличение буфера давало эффект - примерно до 2GB, увеличение до 10 GB не дает эффекта
Dmitry
размер базы около 7ТБ
Mikhail
wal-ы с сжатием?
Dmitry
wal-ы с сжатием?
валы сжимаются wal-g, на самом мастере эта настройка выключена
d
> валы сжимаются на самом мастере думал с завода пишут)
d
А подскажите почему когда у меня в пуле-зеркале из 3 дисков один - медленный диск (WD-шка зелёная) то весь пул начинает тормозить?
d
тормозит как чтение так и запись
d
скорость по самому медленному выстраиваеться, чтобы не потерять данные
Да, а почему? ещё же два быстрых остаются, почему нельзя на них записать и потом уже догнать без тормозов третьим диском?
d
может есть какая-то настройка избыточности?
Vladimir
может есть какая-то настройка избыточности?
есть, называеться архитектор системы(админ)😉
d
есть, называеться архитектор системы(админ)😉
я дома использую. просто купил по дурости задёшево винт и не знаю куда его приткнуть)
d
а он 3.5", неудобно
d
под бэкапы мелкие хороши
Владимир
под бэкапы мелкие хороши
быстро ломаются?)
d
быстро ломаются?)
Меньше весят, удобнее носить
Владимир
проще расколотить))
d
(у меня в компе просто салазки под 2 мелких внешние)
George
Да, а почему? ещё же два быстрых остаются, почему нельзя на них записать и потом уже догнать без тормозов третьим диском?
запись синхронна всегда в мирроре сейчас, а вот чтение с 0.7 умеет разбрасываться
George
recordsize=4,8,32,128 - лучший результат на 8k
16К ещё было бы релевантно, но не сильно скорее всего поможет. а вы несколько vdevs попробовали в итоге под постгрёй?
Алексей
ребята, тупой вопросик пожалуйста позвольте. а zvol можно тонко клонировать?
Dmitry
16К ещё было бы релевантно, но не сильно скорее всего поможет. а вы несколько vdevs попробовали в итоге под постгрёй?
Именно под постгресом нет пока, тк не удаётся пока заставить постгрес писать несколькими процессами, в режиме наката логов работает 90% времени один процесс, поэтому пока запустил на новом пуле с настройками которые обсуждали но на одном диске. Если удастся заставить бграйтер писать больше и это даст прирост производительности то попробуем дотавить диск в страйп
« Rev
@ru_zfs   185
Fwd »