Они в 99 процентах случаев используют агрегацию

Кто реализует эту агрегацию?

Чуть ли не одной операцией

Кто реализует эту агрегацию?

ОС и ЗФС

Данные пишутся по CoW линейно

Тогда почему же fio 4k randwrite и fio 4k write показывает разные результаты (Не 10-20-30% разные, а больше)?

Синхронная запись, скорее всего

Надо смотреть

Там очень много параметров играют

Там очень много параметров играют

Я понимаю как это прозвучит, но о каких параметрах может идти речь, если пул, zvol и fio команда буквально в лоб писались

Синхронная запись, скорее всего

Плюс asyncIO использовался как библиотека для fio

Я понимаю как это прозвучит, но о каких параметрах может идти речь, если пул, zvol и fio команда буквально в лоб писались

Параметров системы и механизмы работы самой фс, а не только ее настройки

В общем, тестирование и разнесением нагрузок часто играет на пользу

Можно выжать хорошие результаты производительности на задачах

Но это небыстрый процесс.

Если тесты рабочей нагрузки (не фио) покажут приемлемые результаты - имеет смысл использовать. Если нет - то нет

Это не простой слой наподобие рейда, тут очень многое играет как в большую сторону, так и в меньшую

Можно выжать хорошие результаты производительности на задачах

Проблема в том что это виртуализация для ~40 ВМ. Которые удаляются, создаются заново. Это может быть Horizon VDI, Cisco FTD, Cisco ISE, Windows AD, MySQL\MariaDB, PosGRES, 1C, Ubuntu\CentOS, Cisco CUCM и т.д и т.п

Проблема в том что это виртуализация для ~40 ВМ. Которые удаляются, создаются заново. Это может быть Horizon VDI, Cisco FTD, Cisco ISE, Windows AD, MySQL\MariaDB, PosGRES, 1C, Ubuntu\CentOS, Cisco CUCM и т.д и т.п

Это список ОС, нагрузка это про другое. Может там будет файлопомойка, может там мускуль сожрет на запись все ио

Может горячий объём не поместится в арк, а может и поместится

Тут только тестировать изучать смотреть

Возвращаюсь: как это устроисвто помогает ворочать медиа файлы ?🤔

Что по вашему мнению значит ворочать? Это чтение, запись? Последовательная или случайная? Просто не вы ли выше писали, что сжатие замедляет сильно на медиа, но не сжимает сильно? Но медиа если не пожмется более, чем на 12,5%, то на блоке будет хранится несжатая версия и в дальнейшем, при её чтении, никакой распаковки не происходит. Значит и разницы нет, в каком режиме работает. Потому чтение, как мне кажется, тут не причем. Тут, скорее всего, где-то ошибка с вашей стороны. Может данные жмутся таки? А про ССД и Zil я написал потому, что вы написали про объем данных и замену шпинделей на ССД. Если хочется с большим iops писать данные - SLOG поможет. Если у вас синхронная запись, конечно же. Поправьте меня, конечно, я могу ошибаться, но в моем понимании блоки данных пишутся в Zil, пока не будут сброшны в пул. А про мелкие блоки, как писали выше, это special device

Это список ОС, нагрузка это про другое. Может там будет файлопомойка, может там мускуль сожрет на запись все ио

Там в том числе виды нагрузок. Логи, БД разного формата и содержания (включая те, что не умеют останавливать запись от слова совсем), CUCM вообще всегда пишет по 40IOPS динамического размера

Тестировать

Тестировать

Что именно? Какое из зол будет наименьшее?

Ага :)

8к наименьшее по результатам fio Для 4к 8к 16к 32к 64к 1м

8к сейчас почти никто не пишет

8к сейчас почти никто не пишет

Расскажите это Cisco и про агрегацию записей тоже

А ещё про остановку БД, а то ВМ Cisco может умереть если делать снапшот

Не думаю, что она даст основную нагрузку 😁

А ещё про остановку БД, а то ВМ Cisco может умереть если делать снапшот

Откуда Cisco не узнает об снапшоте?)

Откуда Cisco не узнает об снапшоте?)

Она видимо расчитывает что грязные страницы точно запишутся

Откуда Cisco не узнает об снапшоте?)

Cisco FTD, Cisco ISE и ещё сколько-то ВМ при миграции или снапшоте (а именно замирании ВМ на 0.1-0.5с) могут убить свою БД. А ещё заодно свою файловую систему (у них нет fsck.ext4 в ОС)

Поэтому от Cisco (которой у меня много в лабе) я бы не особо рассчитывал на умные вещи такие как Агрегация записей, не запись в 4к и т.д.

Поэтому от Cisco (которой у меня много в лабе) я бы не особо рассчитывал на умные вещи такие как Агрегация записей, не запись в 4к и т.д.

Она не создаёт основную нагрузку - можно пренебречь

8к сейчас почти никто не пишет

Ну и наконец, VMware рекомендация форматировать ЛУН для iSCSI в 4к или 8к

Она не создаёт основную нагрузку - можно пренебречь

Их большинство

Их большинство

Не думаю, что они дадут больше, чем бд :)

Ну и наконец, VMware рекомендация форматировать ЛУН для iSCSI в 4к или 8к

Тогда смысла создавать и тестировать на рекордсайзе 64 вообще нет

Не думаю, что они дадут больше, чем бд :)

Они и есть БД

И тестировать надо не локально, цифры будут совершенно другие

И тестировать надо не локально, цифры будут совершенно другие

Я очень сомневаюсь, что при подключении через iSER 40G я увижу цифры больше чем локально...

И тестировать надо не локально, цифры будут совершенно другие

Но да, этим я сейчас и занимаюсь

Я очень сомневаюсь, что при подключении через iSER 40G я увижу цифры больше чем локально...

Меньше :)

Меньше :)

О чём и речь. Теоретический лимит такого подключения 4.8 ГиБ/с

Возвращаюсь: как это устроисвто помогает ворочать медиа файлы ?🤔

Я опираюсь, например, на эти данные http://onreader.mdl.ru/AdvancedZFS/content/Ch07.html Перевод корявый местами, но, вроде бы, понятно

из опыта -- помойка с мрз и оггами жмётся еще процентов на 5-10 zstd

zstd дорогой по процу, 5-10% в абсолютных цифрах не всегда того стоит.

Вопрос. Пробовал на 20.04 (5.4) и на 22.04 (5.15). Кстати ZoL очень хорошо переживает мажорное обновление Есть диск NVMe (форматирован в 512б), который при randwrite direct=1, buf=0, inval=1, bs=8k, iodepth=32, выдаёт 1600 MiB/s Когда на него делается strip zpool: zpool create -o ashift=9 -O compression=lz4 -O atime=off -O recordsize=64k nvme /dev/nvme0n1 Я получаю 147MiB Когда делаю: zpool create -o ashift=9 -O compression=lz4 -O atime=off -O recordsize=8k nvme /dev/nvme0n1 Получаю: 349 MiB/s what the hell? Судя по гуглу - с этим кто-то сталкиваться, но ответы идут из разряда - у вас диск гавно

Вы кстати на сколько диск заполняли при raw тестах? По хорошему честные цифры можно увидеть только после заполнения диска, ибо рандом на пустое пространство ftl соптимизирует

Вы кстати на сколько диск заполняли при raw тестах? По хорошему честные цифры можно увидеть только после заполнения диска, ибо рандом на пустое пространство ftl соптимизирует

Я хороших цифр не вижу с ZFS....

Даже при записи 30Г файла на пустые диски

Я хороших цифр не вижу с ZFS....

Ну zfs на диски не как есть тоже нагрузку даст, и он быстро в перезапись уходит блоков

Ну zfs на диски не как есть тоже нагрузку даст, и он быстро в перезапись уходит блоков

Диски 1ТБ и я писал по 30Г, пересоздавая пул после тестов и ожидая где-то 3-6 минут между тестами

lz4 никак не влияет на результаты fio, по крайней мере, не больше 0.5% recordsize=8к режет максимальную скорость до 1200 миб/с, а если ставить 64к, то скорость конечно 2к миб (при блоках fio 64k), но то это полностью убивает нагрузку в 4к и 8к

Что lz4 не влияет на тесты нулями это странно

Диски 1ТБ и я писал по 30Г, пересоздавая пул после тестов и ожидая где-то 3-6 минут между тестами

Я про raw тесты диска, на которые ориентируетесь

Что lz4 не влияет на тесты нулями это странно

А почему там должны быть нули?

А почему там должны быть нули?

По дефолту поток от fio прекрасно сжимаем

Мб там не нули, но абсолютно однообразный поток

Я про raw тесты диска, на которые ориентируетесь

ext4 (ФС) и mdadm (dev) и mdadm+ext4(ФС) цифры больше дают, чем zvol :(

И, по опыту, зфс учится тестированию через фио и проводит оптимизации. С каждым разом цифры все более отходят от действительности

ext4 (ФС) и mdadm (dev) и mdadm+ext4(ФС) цифры больше дают, чем zvol :(

Я вам про одно, вы про другое) плюс если на zvol тестите то при чём тут recordsize

Я вам про одно, вы про другое) плюс если на zvol тестите то при чём тут recordsize

Тестился dev ext4 mdadm dev mdadm ext4 zpool zvol

И, по опыту, зфс учится тестированию через фио и проводит оптимизации. С каждым разом цифры все более отходят от действительности

Пока они лучше не становятся....

Я дошёл до этапа подключения по сетке. ZFS: zpool create -o ashift=12 -O compression=lz4 -O atime=off -O recordsize=64k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme3n1 -f zfs create -s -V 2.7T -o volblocksize=64k -o compression=lz4 nvme/iser fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=100 --time_based=1 -numjobs=4 -bs=64k -iodepth=32 -rw=randwrite -filename=/dev/mapper/mpat WRITE: bw=916MiB/s (960MB/s), 229MiB/s-229MiB/s (240MB/s-240MB/s), io=54.1GiB (58.0GB), run=60460-60460msec mdadm: fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=100 --time_based=1 -numjobs=1 -bs=64k -iodepth=32 -rw=randwrite -filename=/dev/mapper/mpathd WRITE: bw=1748MiB/s (1833MB/s), 1748MiB/s-1748MiB/s (1833MB/s-1833MB/s), io=121GiB (130GB), run=71062-71062msec

А в много потоков?

По чтению вопросов нет, ZFS на 4-5 тест показывает скорость выше за счёт ARC Но сейчас на TrueNAS у меня нагрузка выглядит так (в простое):

А в много потоков?

ZFS уже был в 4 потока?

А, да, вижу

ZFS уже был в 4 потока?

А если например в 16?

В 32 потока да, Получаю вот это: WRITE: bw=1229MiB/s (1289MB/s), 37.6MiB/s-39.2MiB/s (39.4MB/s-41.1MB/s), io=61.7GiB (66.2GB), run=51350-51387msec Только тут один клиент тогда получает производительность HDD

Судя по mdadm (fio bs=64k numjobs=16 или 32) потолок mpath канала сейчас 2.3 GiB P.S. а ещё у меня randwrite > randread на mdadm

zstd дорогой по процу, 5-10% в абсолютных цифрах не всегда того стоит.

хзхз. я както экспериментировал на десктопном винте (1шт) и разных уровнях. явно был оптимум по скорости при средних коэффах упаковки

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

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

На nvme zstd уже уприается в проц, по крайне мере на моём 6 ядерном (12t) ноуте. При lz4 скорость линейной записи bs=4m, под 900мб/с, При zstd bs=4m, прыгает от 200 до 400 мб/с. И процессор при этом хорошо грузится. На lz4 вообще не заментно.

На nvme zstd уже уприается в проц, по крайне мере на моём 6 ядерном (12t) ноуте. При lz4 скорость линейной записи bs=4m, под 900мб/с, При zstd bs=4m, прыгает от 200 до 400 мб/с. И процессор при этом хорошо грузится. На lz4 вообще не заментно.

на нвме само собой )

на нвме само собой )

На обычном десктопном ssd примерно так же, но поменьше аффектитися, да.

На nvme zstd уже уприается в проц, по крайне мере на моём 6 ядерном (12t) ноуте. При lz4 скорость линейной записи bs=4m, под 900мб/с, При zstd bs=4m, прыгает от 200 до 400 мб/с. И процессор при этом хорошо грузится. На lz4 вообще не заментно.

на каком уровне сжатия zstd кстати? а то там разные есть

на каком уровне сжатия zstd кстати? а то там разные есть

На дефолтном, compression=zstd. На максимальном, на 19, там вообще 10-20мб/с.

На дефолтном, compression=zstd. На максимальном, на 19, там вообще 10-20мб/с.

а на минимальном?

По чтению вопросов нет, ZFS на 4-5 тест показывает скорость выше за счёт ARC Но сейчас на TrueNAS у меня нагрузка выглядит так (в простое):

А Truenas 12 или 13 ?

А Truenas 12 или 13 ?

12.0U6.1 Он собственно как поставился 239 дня назад - так и работает

а на минимальном?

Не пробовал, меня стандартный уровень сжатия в zstd устраивает, а если нужно быстрее, то просто беру lz4. Потом попробую zstd-1, и гляну, как он отличается от zstd.