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

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

По тому что перед завершением любой транзакции надо актуализировать таблицу дедупликации, которая зранится на этом dedup vdev. Там изменится сотня байт, но перезаписывать приходится целый сектор. Таких операцийочень много.

а где тогда этот хвалёный CoW

Неужели всё так плохо

По моему все просто прекрасно (по сравнению с тем как это работает на hdd или обычных ssd - никак не работает). Допускаю, чио за последние год-два могло улутшиться. Результаты не очееь актуальные.

а где тогда этот хвалёный CoW

ну как его тут применить? Самое хорошее - использовать оптайны.

а где тогда этот хвалёный CoW

*RoW И он не уберёт Вам запись в конечно счёте. Отложит - да, но не уберёт

And those dedup Devices confuse me, especially since i can't find any good documentation about them. нигде не могу найти инфу про эти девайсы

Со специальным vdev тмпа dedup. Наэто устройство упадет очень много записи и по iops и по объёму, возможно в 100 раз брльше записанных данных. Мой опыт показал, что при коэффициеете сжатия 2.5х и дедупликации в районе 3х при использовании зеркала из sata intel s3700 можно записывать данные со скоростью ~100Мбит/сек до сжатия и дедупликации, а при использовании в качестве vdev dedup накопителя nvme intel optane 900P или 905P (500 000 iops на запись), скорость записи будет около 1ГБит в секунду (100МБ в сек)

2-3 года назад я тестировал FreeNAS для хранения бекапов: - пул был всего из одного HDD - сжатие lz4 - дедупликация Отдавал по NFS датасет, данные (qcow) всегда писались c линейной скоростью HDD-источника - около 180Мб/с (1,5Гб/с). Сжатие при этом было гораздо хуже вашего - 1.2х, дедупликация с каждой копией увеличивалась, доходила до 20х, когда я удалил всё это дело. Так что цифры в 100Мбит/с на SSD кажутся невероятно малыми.

And those dedup Devices confuse me, especially since i can't find any good documentation about them. нигде не могу найти инфу про эти девайсы

Я в man zpool-create нашел отсылку к man zpoolconcepts и сразу понял что к чему. Попробовал - работает! man zpoolconcepts ... dedup A device dedicated solely for deduplication tables. The redundancy of this device should match the redundancy of the other normal devices in the pool. If more than one dedup device is specified, then allocations are load-balanced between those devices.

2-3 года назад я тестировал FreeNAS для хранения бекапов: - пул был всего из одного HDD - сжатие lz4 - дедупликация Отдавал по NFS датасет, данные (qcow) всегда писались c линейной скоростью HDD-источника - около 180Мб/с (1,5Гб/с). Сжатие при этом было гораздо хуже вашего - 1.2х, дедупликация с каждой копией увеличивалась, доходила до 20х, когда я удалил всё это дело. Так что цифры в 100Мбит/с на SSD кажутся невероятно малыми.

Возможно важно что у меня нагрузка была исключительно из zfs receive а основной vdev был raid-z1 из 5-ти дисков, что эквивалентно по производительности iops одному диску на запись.

2-3 года назад я тестировал FreeNAS для хранения бекапов: - пул был всего из одного HDD - сжатие lz4 - дедупликация Отдавал по NFS датасет, данные (qcow) всегда писались c линейной скоростью HDD-источника - около 180Мб/с (1,5Гб/с). Сжатие при этом было гораздо хуже вашего - 1.2х, дедупликация с каждой копией увеличивалась, доходила до 20х, когда я удалил всё это дело. Так что цифры в 100Мбит/с на SSD кажутся невероятно малыми.

По сжатию, попробуйте zstd-19

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

По сжатию, попробуйте zstd-19

Я тестировал разные уровни zstd, на 19м у вас ещё хорошая скорость получилась)) Видимо за счёт дедупликации как раз и повышалась!

2-3 года назад я тестировал FreeNAS для хранения бекапов: - пул был всего из одного HDD - сжатие lz4 - дедупликация Отдавал по NFS датасет, данные (qcow) всегда писались c линейной скоростью HDD-источника - около 180Мб/с (1,5Гб/с). Сжатие при этом было гораздо хуже вашего - 1.2х, дедупликация с каждой копией увеличивалась, доходила до 20х, когда я удалил всё это дело. Так что цифры в 100Мбит/с на SSD кажутся невероятно малыми.

А ещё, я использую volblocksize=16K, что ускоряет работу баз данных на гипервизоре, уменьшает накладные расходы места на контрольные суммы, удобнее для работы поверх 2-х зеркал и улучшает сжатие при бекапе. Но надо учесть что если там, нпример ntfs а в ней 1С, то надо форматировать диск на этапе инсталяции ОС с параметрами unit=16K, а потом 1С переконвертировать в recordsize=16K (по умолчаниюу и там и там 8К)

Я тестировал разные уровни zstd, на 19м у вас ещё хорошая скорость получилась)) Видимо за счёт дедупликации как раз и повышалась!

Не-не, когда тестировал использовал gzip-9. Проц E3-1240v2, но если бы я заметил что упирается с процессор, то понизил бы степень сжатие. Я уже подробностей не помню. zstd жмет ещё лучше! Но я тогда о нем не знал.

А ещё, я использую volblocksize=16K, что ускоряет работу баз данных на гипервизоре, уменьшает накладные расходы места на контрольные суммы, удобнее для работы поверх 2-х зеркал и улучшает сжатие при бекапе. Но надо учесть что если там, нпример ntfs а в ней 1С, то надо форматировать диск на этапе инсталяции ОС с параметрами unit=16K, а потом 1С переконвертировать в recordsize=16K (по умолчаниюу и там и там 8К)

В ntfs, вроде бы как, по умолчанию 4К) У меня для хранения образов датасет был, потому recordsize=1M

Не-не, когда тестировал использовал gzip-9. Проц E3-1240v2, но если бы я заметил что упирается с процессор, то понизил бы степень сжатие. Я уже подробностей не помню. zstd жмет ещё лучше! Но я тогда о нем не знал.

gzip однопоточный и при 9 степени крайне медленный

В ntfs, вроде бы как, по умолчанию 4К) У меня для хранения образов датасет был, потому recordsize=1M

емнип дефолт там 32-64k

В ntfs, вроде бы как, по умолчанию 4К) У меня для хранения образов датасет был, потому recordsize=1M

Вы можете посмотреть прямо на своем ПК, там 8К. И во всех БД виндовых по умолчанию 8К

емнип дефолт там 32-64k

Не-не. 64 - это максимум.

Вы можете посмотреть прямо на своем ПК, там 8К. И во всех БД виндовых по умолчанию 8К

В бд 8к, но винда только серверная, насколько помню, без танцев с бубном умеет жить на более чем 4К

gzip однопоточный и при 9 степени крайне медленный

Возможно я понижал степень сжатия. Я уже точно не помню. А сейчас дедупликация не используется, т.к. задача исчезла.

В бд 8к, но винда только серверная, насколько помню, без танцев с бубном умеет жить на более чем 4К

Никаких проблем не встречал ни с серверными ни с клиентскими. diskpart sel desk ... sel part ... format fs=ntfs unit=16K quick

емнип дефолт там 32-64k

Это то, что 10ка создает по умолчанию

Это то, что 10ка создает по умолчанию

А у меня 8К создавала... может по тому что volblocksize в проксмоксе по умолчанию 8К?

А у меня 8К создавала... может по тому что volblocksize в проксмоксе по умолчанию 8К?

Так у неё выбора, получается, особого не было))

Ну, в любом случае, 16К ещё лучше )

Ну, в любом случае, 16К ещё лучше )

Для сжатия, количества меты и, само собой, дедупликации, конечно)) А если больше, то ещё лучше)

Правда тогда производительность блоков меньше умирает

Коллеги добрый день! не могу победить низкий IOPs при случайном чтении из пула состоящего из 6 vdev raidz1 каждый по 5 дисков SAS 7200 16TB сектор 4к линейная запись упирается в контроллер, линейно чтение медленнее - но не критично. Случайная синхронная запись тоже не проблема только random sync read может кто сталкивался?

Коллеги добрый день! не могу победить низкий IOPs при случайном чтении из пула состоящего из 6 vdev raidz1 каждый по 5 дисков SAS 7200 16TB сектор 4к линейная запись упирается в контроллер, линейно чтение медленнее - но не критично. Случайная синхронная запись тоже не проблема только random sync read может кто сталкивался?

16TB - smr наверно ?

Vendor: WDC Product: WUH721816AL5204 Revision: C232 Compliance: SPC-5 User Capacity: 16,000,900,661,248 bytes [16.0 TB] Logical block size: 4096 bytes LU is fully provisioned Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca2a1ce65f8 Serial number: 2CKNHVVN Device type: disk Transport protocol: SAS (SPL-3) Local Time is: Tue Aug 23 14:37:15 2022 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled

а под арк сколько памяти ?

на хосте 256ГБ

сейчас ARC зажат. на пуле выключен кэш для данных - только для мета

Коллеги добрый день! не могу победить низкий IOPs при случайном чтении из пула состоящего из 6 vdev raidz1 каждый по 5 дисков SAS 7200 16TB сектор 4к линейная запись упирается в контроллер, линейно чтение медленнее - но не критично. Случайная синхронная запись тоже не проблема только random sync read может кто сталкивался?

А низкий - это сколько IOPS?

Коллеги добрый день! не могу победить низкий IOPs при случайном чтении из пула состоящего из 6 vdev raidz1 каждый по 5 дисков SAS 7200 16TB сектор 4к линейная запись упирается в контроллер, линейно чтение медленнее - но не критично. Случайная синхронная запись тоже не проблема только random sync read может кто сталкивался?

Если посчитать, получится около 30К IOPS теоретически.

Коллеги добрый день! не могу победить низкий IOPs при случайном чтении из пула состоящего из 6 vdev raidz1 каждый по 5 дисков SAS 7200 16TB сектор 4к линейная запись упирается в контроллер, линейно чтение медленнее - но не критично. Случайная синхронная запись тоже не проблема только random sync read может кто сталкивался?

Это как - упирается в контролёр ? Контролёр может 48 гигабит прожевать, даже 96 в дуплексе , если он 12g. 30 винтов и близко такую скорость не дадут , что вы. А если hba 6g и подавно

Это как - упирается в контролёр ? Контролёр может 48 гигабит прожевать, даже 96 в дуплексе , если он 12g. 30 винтов и близко такую скорость не дадут , что вы. А если hba 6g и подавно

контроллер SAS2

выше 2ГБ/с не вижу без мультипас

сейчас работают две полки по 15 дисков

контроллер SAS2

Sas2 умеет 48 в полный дуплекс. Все равно вы его не выжираете

выше 2ГБ/с не вижу без мультипас

Мультипас с 30 дисками по мне вообще смысла не имеет Полки видимо как у меня emc ))

да - они

да - они

Короче контролёр не при чем

Короче контролёр не при чем

в теории должно быть где-то 2500МБ - что в моем сценарии уже не сильно критично

в теории должно быть где-то 2500МБ - что в моем сценарии уже не сильно критично

Это слишком идеальный условия 🤷🏻‍♂️

Это слишком идеальный условия 🤷🏻‍♂️

система тестовая - без нагрузки. как писал выше - не могу понять сколько можно (должно быть) получить IOPs в случайном чтении 4-128кБ

система тестовая - без нагрузки. как писал выше - не могу понять сколько можно (должно быть) получить IOPs в случайном чтении 4-128кБ

А сколько сейчас iops получается на случайном чтении?

А сколько сейчас iops получается на случайном чтении?

fio [global] name=random-read-job ioengine=libaio direct=1 sync=1 time_based runtime=60 group_reporting=0 size=50g [write-dataset-128k] iodepth=1 rw=randread bs=128K numjobs=32 filename=/external-sas/data128k-write

сейчас сделаю замер, пять сек

read-dataset-128k: (g=0): rw=randread, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=psync, iodepth=1 ... fio-3.25 Starting 32 processes Jobs: 32 (f=32): [r(32)][100.0%][r=331MiB/s][r=2646 IOPS][eta 00m:00s] read-dataset-128k: (groupid=0, jobs=32): err= 0: pid=2780133: Tue Aug 23 15:54:31 2022 read: IOPS=3372, BW=422MiB/s (442MB/s)(24.7GiB/60022msec) clat (usec): min=13, max=1502.9k, avg=9483.80, stdev=21600.42 lat (usec): min=13, max=1502.9k, avg=9483.98, stdev=21600.42 clat percentiles (usec): | 1.00th=[ 42], 5.00th=[ 45], 10.00th=[ 46], | 20.00th=[ 48], 30.00th=[ 51], 40.00th=[ 59], | 50.00th=[ 6783], 60.00th=[ 11469], 70.00th=[ 15139], | 80.00th=[ 18744], 90.00th=[ 23987], 95.00th=[ 28443], | 99.00th=[ 38536], 99.50th=[ 42730], 99.90th=[ 57934], | 99.95th=[ 74974], 99.99th=[1468007] bw ( KiB/s): min=19712, max=10712064, per=100.00%, avg=439029.52, stdev=63827.58, samples=3753 iops : min= 154, max=83688, avg=3429.92, stdev=498.65, samples=3753 lat (usec) : 20=0.02%, 50=28.65%, 100=20.61%, 250=0.04%, 500=0.01% lat (usec) : 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 4=0.02%, 10=6.70%, 20=26.62%, 50=17.12% lat (msec) : 100=0.18%, 250=0.01%, 500=0.02%, 2000=0.02% cpu : usr=0.04%, sys=0.74%, ctx=103321, majf=0, minf=1457 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=202435,0,0,0 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): READ: bw=422MiB/s (442MB/s), 422MiB/s-422MiB/s (442MB/s-442MB/s), io=24.7GiB (26.5GB), run=60022-60022msec

но если делать в один поток - скорость случайного чтения из пула read: IOPS=176, BW=22.1MiB/s (23.2MB/s)(1327MiB/60001msec) clat (usec): min=21, max=35997, avg=5648.71, stdev=4481.83 lat (usec): min=21, max=35997, avg=5648.89, stdev=4481.83

не могу понять - это вообще нормально для пула из шести групп по пять дисков?

не могу понять - это вообще нормально для пула из шести групп по пять дисков?

А там у вас файлы или zvol?

Для однопоточной нагрузки, насколько я понимаю, да. откуда возьмется ускорение, если все упирается в латентность. А латентность у механики не ахти, т.к. надо ждать когда шпиндиль повернется в нужное положение чтобы считать нужный сектор. А значит ускорение дает только многопоточное чтение. А в многопоточном у вас и получается 30 дисков* 100 iops = 3000 IPOS. а у вас 3300 IOPS (иногда диски за оборот могут несколько чтений селать, если повезёт) Но в целом IOPS ограничиваются количеством оборотов. Ведь пока сектор не доедет до головки, как бы быстро она не позиционировалась, билн вращается с одной и тойде скоростью.

В идеальных условиях 7200RPM/60 секунд=120 IOPS дает один диск. Но я заметил что смело можно считать что 100, остальное - это метаданные, диски мешают друг другу видрацией и другие факторы.

Если посчитать, получится около 30К IOPS теоретически.

Тут я дал маху, нолик лишний приписал. 3К IOPS конесно же.

А там у вас файлы или zvol?

файлы я сейчас разберу пул - и сделаю софтрейд пятого уровня

дропну кэш и сниму fio с в один поток и в 32

да - они

А у вас полки друг в друга или в разные дырки ?

независимые порты

сравнение в случайном чтении mdadm5 и raidz1

конфигурацию стенда привел в одинаковые условия - 5 дисков в одной полке, разделы выровнены по границе 4к

сравнение в случайном чтении mdadm5 и raidz1

Не фатально. Разница не в пользу zfs - это норма ) Кое что надо знать об этих результатах. Ещё только появился zfsonlinux, а у меня была проблема: softraid raid10 из 10 дисков 10k rpm поверх коьорого был lvm с образами libvirt-виртуальных машин упирался в iops. Когда ситуауия усугибилась, попробовпли zfs и нагрузка упала процентов на 90. есть методика позволчющая записать реальную нагрузку и проигрывать её на реальные блочные устройства.

конфигурацию стенда привел в одинаковые условия - 5 дисков в одной полке, разделы выровнены по границе 4к

Но было бы интересно на 30 дисках в raid5+0 запустить fio

конфигурацию стенда привел в одинаковые условия - 5 дисков в одной полке, разделы выровнены по границе 4к

Я думаю, чтобы было честно, нажо метаданные вынести с пула на special vdev, результаты станут лучше.

момент

это можно

Я думаю, чтобы было честно, нажо метаданные вынести с пула на special vdev, результаты станут лучше.

Если это будите тестировать, то special должен быть на ssd, чтобы латентность не мешала.

nvme samsung pm983

pool: external-sas state: ONLINE config: NAME STATE READ WRITE CKSUM external-sas ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 s1-d00-part1 ONLINE 0 0 0 s1-d01-part1 ONLINE 0 0 0 s1-d02-part1 ONLINE 0 0 0 s1-d03-part1 ONLINE 0 0 0 s1-d04-part1 ONLINE 0 0 0 special mirror-2 ONLINE 0 0 0 slog1-part2 ONLINE 0 0 0 slog1-part3 ONLINE 0 0 0 logs slog1-part1 ONLINE 0 0 0

Лог не влияет на чтение, а на записи, вся синхронная запись свалится на него. Но чтение можно проверять

Только момент

зеркало из одной и той же ssd очень плохая идея

Лучше оставить один диск.

zpool ругнется и откажется создавать пул, но ключ -f убедит его что мы не сошли с ума.

не собирается vdev без зеркала