какие с вашей точки зрения использовать правильные тесты с какими параметрами. Ранее вы критиковали тестирование OpenZFS на FreeBSD. в статье на phoronix

какие с вашей точки зрения использовать правильные тесты с какими параметрами. Ранее вы критиковали тестирование OpenZFS на FreeBSD. в статье на phoronix

ну и нет "правильных тестов", есть тесты на конкретный профиль нагрузки

ну и нет "правильных тестов", есть тесты на конкретный профиль нагрузки

тогда в чем он был неправ автор на phoronix. Никаких конкретных замечаний в комментариях я не нашел.

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

вообще ничего не нашли?) хорошей базой везде считается использование fio, дальше по профилю нагрузки подбирается

вот для начала пачка конфигов fio https://github.com/openzfs/zfs/tree/master/tests/zfs-tests/tests/perf/fio

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

> нет, однозначно нельзя, т.к. для некоторых нагрузок такие параметры могут быть адекватными по дефолту при таком подходе SSD используется неэффективно (с дефолтными параметрами), а если выкрутить их значения, то HDD однозначно работают медленнее, поэтому я и считаю, что если есть два пула на разных типах носителях, значит будет либо одно, либо другое, либо середина - ни туда ни сюда. Напрашивается вывод, не использовать разные типы носителей на одном хосте либо добавить к пулам с HDD ZIL и L2ARC. Да, я понимаю, что при дефолтных значения SSD тоже всегда быстрее HDD, но КПД далеко не максимальный.

ну не касаемо zfs стоит изучать как fio используют, под рукой нет инструкции всеобъясняющей, стоит смотреть примеры и читать доку про параметры, там кучу вариантов нагрузки можно замерить. а касаемо zfs стандартные нюансы: - xattrs - compression - recordsize - ashift в контексте raidz - время тестирования должно учитывать свободное место в пуле и фрагментацию, заполненность zvol ну и касаемо ssd/nvme: - время тестирования должно учитывать деградацию производительности носителя при заполнении

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

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

а насколько удалось ускорить/оптимизировать производительность пула на ссд через выкручивание этого параметра?

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

опции эти применяются к vdev-ам , а не к пулам, неважно в каком типе пула состоит vdev количество очередей направленный в его сторону будет таким какое указано в параметрах модуля zfs. Подмешивать сюда влияние конфигураций пулов никакого смысла нет, если задача стоит протестировать именно влияние zfs_vdev_sync_read_max_active zfs_vdev_sync_write_max_active и тому подобных параметров модуля. Результаты можно интерполировать уже на пулы на разных носителях (vdev-ах), где добавятся влияние их конфигураций.

на vdevs то распространяется это понятно, но вы не можете читать/писать только на один vdev в пуле, гарантировать 100% равномерную нагрузку по vdevs тоже нельзя = результаты теста однозначно интерпретировать нельзя

такое ощущение что вы не хотите меня слышать или делайте вид что не понимаете о чем идет речь. Еще раз, не важно, как работает vdev в пуле в котором он один или их восемь таких же как он, если нагрузка на любого из них в пуле в какой-то момент времени будет равномерная или неравномерная это ничего не решат с точки зрения определения влияния этих параметров. для чего вы пытаетесь подмешать сюда толи общую производительность пула, толи чего... Когда на vdev который в пуле из многих ему подобных или нет, выстроиться очередь в 100 определенная параметром например zfs_vdev_sync_write_max_active, а он при этом HDD то производительность его существенно просядет, а если он nvme то легко справиться, если задать очередь в 10-ть то и HDD отработает относительно неплохо, а для nvme это уже будет неэффективно. Для чего вы мешаете сюда пулы, если речь идет про работу с конкретным vdev-ом неважно в одиночку он работает или нет, все равно очередь на него не будет больше чем она будет задана в параметрах модуля.

ну проще всего тестировать vdev когда он один в пуле, например, я про это

ну и я то же об этом

А как лучше зфс профилировать? Есть какие-нибудь практики на этот счёт?

@gmelikov Георгий, в подкасте вы говорите что ECC для ZFS на столько же важна, насколько и для других ФС, ведь на деле это не так, ZFS рискует больше по-моему, например при том же resilvering-е пул скорее всего тут же развалиться в случае наличия битой памяти.

Все примеры с битой памятью что мне попадались на форумах были про останавливающийся скруб по причине too many errors

И это кажется допустимым?

в смысле? Каждый сам для себя решает ставить ECC или нет

Я о наличии самого факта поврежденных данных

Все примеры с битой памятью что мне попадались на форумах были про останавливающийся скруб по причине too many errors

@gmelikov Георгий, в подкасте вы говорите что ECC для ZFS на столько же важна, насколько и для других ФС, ведь на деле это не так, ZFS рискует больше по-моему, например при том же resilvering-е пул скорее всего тут же развалиться в случае наличия битой памяти.

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

И это ситуации когда память вышала из строя аппаратно, а может быть ситуация, когда значение в ячейке меняется под воздействием внешних факторов и такое изменение не может быть выявлено если нет ECC (silent data corruption). Чем меньше техпроцесс тем меньше энергии нужно чтобы изменить состояние бита. Интересно как люди не использующие ECC в продакшен могут спокойно спать.

тогда в чем он был неправ автор на phoronix. Никаких конкретных замечаний в комментариях я не нашел.

» 1GB of RAM for every 1TB of disk О мы на форуме насостроителей докапались до первоисточника этого типа правила. Там речь шла о DDT

» 1GB of RAM for every 1TB of disk О мы на форуме насостроителей докапались до первоисточника этого типа правила. Там речь шла о DDT

ddt - до 320байт на 1 блок (recordsize), вот правило

не так давно читал статью про zfs и там это было написано практически прямым текстом

да это везде пропихивают, замучался спорить

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

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

вот пример комментов адекватных о форониксе https://www.phoronix.com/forums/forum/software/bsd-mac-os-x-hurd-others/1067255-freebsd-zfs-vs-linux-ext4-btrfs-raid-with-twenty-ssds/page2 , ryao - один из контрибьюторов, можно его комменты по статье искать

И это ситуации когда память вышала из строя аппаратно, а может быть ситуация, когда значение в ячейке меняется под воздействием внешних факторов и такое изменение не может быть выявлено если нет ECC (silent data corruption). Чем меньше техпроцесс тем меньше энергии нужно чтобы изменить состояние бита. Интересно как люди не использующие ECC в продакшен могут спокойно спать.

Есть большое колличество оверклокеров у которых память работает в предельных а ещё чаще запредельных режима, они регулярно ловят бсоды и по теории их ntfs должен падать каждый день, но в реальности этого не случается, падения есть но их так мало что тема гонева даже не ассоциируется с факапами.

Есть большое колличество оверклокеров у которых память работает в предельных а ещё чаще запредельных режима, они регулярно ловят бсоды и по теории их ntfs должен падать каждый день, но в реальности этого не случается, падения есть но их так мало что тема гонева даже не ассоциируется с факапами.

ну да, и ось каждый месяц переставлять норма, кек

Есть большое колличество оверклокеров у которых память работает в предельных а ещё чаще запредельных режима, они регулярно ловят бсоды и по теории их ntfs должен падать каждый день, но в реальности этого не случается, падения есть но их так мало что тема гонева даже не ассоциируется с факапами.

задача: кэш нжинкса. нужно держать 50мб/с с одного hdd. чтение/запись примерно 4:1. в компе 4 hdd и 1 ssd файлы двух типов: относительно крупные (средний размер свыше 20Мб) и мелкие (их много, но общий размер меньше 100ГБ). что хочу сделать: сделать на SSD 4 раздела (по разделу на каждый HDD) по 200ГБ. собрать на каждом HDD отдельный zfs со своим special. поставить recodsize 4МБ, в special класть записи меньше 2МБ (прикинул, должно хватить) рассуждал так: отдача в основном линейная, но многопоточная (много одновременных запросов от разных клиентов). выгоднее читать в память относительно большими кусками и отдавать уже из памяти (чтобы снизить iops на hdd) ну и метаданные/мелкие файлы лучше размещать на ssd покритикуйте, плиз

задача: кэш нжинкса. нужно держать 50мб/с с одного hdd. чтение/запись примерно 4:1. в компе 4 hdd и 1 ssd файлы двух типов: относительно крупные (средний размер свыше 20Мб) и мелкие (их много, но общий размер меньше 100ГБ). что хочу сделать: сделать на SSD 4 раздела (по разделу на каждый HDD) по 200ГБ. собрать на каждом HDD отдельный zfs со своим special. поставить recodsize 4МБ, в special класть записи меньше 2МБ (прикинул, должно хватить) рассуждал так: отдача в основном линейная, но многопоточная (много одновременных запросов от разных клиентов). выгоднее читать в память относительно большими кусками и отдавать уже из памяти (чтобы снизить iops на hdd) ну и метаданные/мелкие файлы лучше размещать на ssd покритикуйте, плиз