ну зависит, если битрикс - там 3 гигабайта плохого кода и 50 гигабайт медиа на сайт - запросто

в итоге мне на самом деле больше подходит то, что походит на flashcache - один ссд + один крутящийся диск, но такого, к сожалению, нет в зфс

сильная разница?

если файл/большой кусок данный отдаётся клиенту за раз, то за счёт увеличения recordsize будет меньше seek time при чтении с диска, пока фрагментация пула небольшая и он может записывать файлы последовательно (если мы их последовательно пишем) - разница минимальна, но как только это условие не сработает то +10мс seek time на каждый кусок. Относительные цифры зависят от фрагментации, в общем.

в итоге мне на самом деле больше подходит то, что походит на flashcache - один ссд + один крутящийся диск, но такого, к сожалению, нет в зфс

l2arc персистентный стал, если что, может в вашем кейсе подойдёт

l2arc + slog + special class и hdd для обычного vdev могут тут помочь

вот только special class работает не как slog

что приводит к требованию зеркала, а это дорого

если бы он постепенно уезжал на обычный диск - совсем другое дело было бы

вот только special class работает не как slog

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

Не появилось в ZFS средство борьбы с 20% деградации скорости?

Не появилось в ZFS средство борьбы с 20% деградации скорости?

А подробнее?

А подробнее?

При более 80% занятости пула падение перфоманце В моем случае FTP сервер и даже 5% от 300TB не является критичным, но скорость начинает падать в разы, особенно на менее 10% свободного

При более 80% занятости пула падение перфоманце В моем случае FTP сервер и даже 5% от 300TB не является критичным, но скорость начинает падать в разы, особенно на менее 10% свободного

Насколько я понимаю, это практически фича

Насколько я понимаю, это практически фича

Как ее отрубить к ...

Как ее отрубить к ...

Ее нельзя отрубить. Когда у нас остается мало свободного места, приходится постоянно переписывать журнал.

Это не искусственное замедление, это так работает алгоритм.

Я понимаю это

просто думаю есть ли хак

То что архитектурно так давно знаю)

... а вот есть такая фича у lz4, этот алгоритм не жмет картинки. Как включить, чтоб жало?

Картинки итак упакованы, их сжатие очень неэффективно

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

Картинки итак упакованы, их сжатие очень неэффективно

... я пытаюсь объяснить @Oller22 что невозможно "выключить" замедление ZFS при 90% заполнении пула

просто думаю есть ли хак

Можно выставить квоту на объем вашего хранилища, вы теряете в доступном месте, но производительность не упадет, способов то особо нет

просто думаю есть ли хак

Есть ли хак, чтобы lz4 хорошо жал видео?

Есть ли хак, чтобы lz4 хорошо жал видео?

смена lz4 на другой алгоритм

)

Закрыли етму

смена lz4 на другой алгоритм

... ооок. Есть ли хак, чтобы сжимать видео алгоритмом без потерь данных хотя бы на 20%?

... ооок. Есть ли хак, чтобы сжимать видео алгоритмом без потерь данных хотя бы на 20%?

Зависит строго от видео;)

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

При более 80% занятости пула падение перфоманце В моем случае FTP сервер и даже 5% от 300TB не является критичным, но скорость начинает падать в разы, особенно на менее 10% свободного

В свежих версиях openzfs были фиксы на эту тему, улучшающие ситуацию, емнип

В свежих версиях openzfs были фиксы на эту тему, улучшающие ситуацию, емнип

Это уже интересно, от какой примерно не помните?

Нет, по ченджлогам стоит попрыгать

ну вообще очевидный вариант - вынести журнал на отдельный диск и снизить дефрагментацию

При более 80% занятости пула падение перфоманце В моем случае FTP сервер и даже 5% от 300TB не является критичным, но скорость начинает падать в разы, особенно на менее 10% свободного

к этому

ну вообще очевидный вариант - вынести журнал на отдельный диск и снизить дефрагментацию

+1, мета это мелкоблок и способствует фрагментации

ну вообще очевидный вариант - вынести журнал на отдельный диск и снизить дефрагментацию

Вот с этого момента поподробнее, на на работающем пуле можно?

Вот с этого момента поподробнее, на на работающем пуле можно?

Гугли special vdev - это о нём речь. Не уверен на все сто, но думаю добавить его к существующему пулу проблем нет Но есть такой момент: special нужно зеркалить, ибо его смерть похоронит заодно и весь пул

Гугли special vdev - это о нём речь. Не уверен на все сто, но думаю добавить его к существующему пулу проблем нет Но есть такой момент: special нужно зеркалить, ибо его смерть похоронит заодно и весь пул

Классика

Гугли special vdev - это о нём речь. Не уверен на все сто, но думаю добавить его к существующему пулу проблем нет Но есть такой момент: special нужно зеркалить, ибо его смерть похоронит заодно и весь пул

Special Allocation Class — это специальный Vdev, куда пишутся метаданные или блоки данных меньше 4 килобайт (запись данных конфигурируется). Получается, что под большие блоки данных можно использовать медленное, но дешевое HDD-хранилище, а рядом поставить SSD-диски, хранящие его по блоки метаданных и блоки данных небольших размеров.

не пойму как решит вопрос записи больших файлов

zil и arc понятно и сейчас вынесу-потестирую

Special Allocation Class — это специальный Vdev, куда пишутся метаданные или блоки данных меньше 4 килобайт (запись данных конфигурируется). Получается, что под большие блоки данных можно использовать медленное, но дешевое HDD-хранилище, а рядом поставить SSD-диски, хранящие его по блоки метаданных и блоки данных небольших размеров.

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

Диск сюда нужен с юатерейкой явно

Но весьма интересно

спасибо за наводку

итого 5 дисков под кеши так понимаю нужно

Четное число

2 special, 2log, 1arc

2 special, 2log, 1arc

log - насколько я мог его разглядеть - ничего не ускоряет, по крайней мере, я не добился

хотя по идее терабайтник поделить на 3 раздела?

log - насколько я мог его разглядеть - ничего не ускоряет, по крайней мере, я не добился

кто-то еще тут может подтвердить эту гипотезу? Если что вопрос не к Александру

хотя по идее терабайтник поделить на 3 раздела?

Суть отдельного лога не в том, чтобы его с чем-то разделять. Это отдельный vdev должен быть

log - насколько я мог его разглядеть - ничего не ускоряет, по крайней мере, я не добился

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

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

Да много ли там той синхронной записи

2 special, 2log, 1arc

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

Да много ли там той синхронной записи

Бд обычно

Если синхронной записи нет то slog не нужен особо

Бд обычно

А вот интересно. можно ли как-то посмотреть, сколько там тех синхронных записей?

Если синхронной записи нет то slog не нужен особо

Не бд, ftp и подобная нпгрузка

А вот интересно. можно ли как-то посмотреть, сколько там тех синхронных записей?

Zpool iostat

Не бд, ftp и подобная нпгрузка

Wat? Какой фтп нынче)

Wat? Какой фтп нынче)

Объясни клиентам полугосов))

Я даже не помню пытается ли фтп сервер среднестатистический синк делать при записи

Объясни клиентам полугосов))

Ну это частный кейс, а классический - всё же бд

Zpool iostat

syncq_wait?

Мне тут один тв канал выгрузкой дал ftp, который половину команд вообще не умеет))), так к слову больше

syncq_wait?

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

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

Если найдешь заклинание, не обломайся сюда кинуть

Ну и самый простой вариант понять поможет ли slog - на время выставить sync=disabled (с пониманием, что на это время при потере питания синхронная запись потеряется) и посмотреть есть ли разница

Ну и самый простой вариант понять поможет ли slog - на время выставить sync=disabled (с пониманием, что на это время при потере питания синхронная запись потеряется) и посмотреть есть ли разница

А вот кстати интересная тема

Ну и самый простой вариант понять поможет ли slog - на время выставить sync=disabled (с пониманием, что на это время при потере питания синхронная запись потеряется) и посмотреть есть ли разница

Я на датасет с БД под Битрикс выключал, запускал встроенный тест битрикс - ноль на массу. Потом включил always - количество операций записи и изменения снизилось в 10 раз. Пул из двух nvme в зеркале

Я на датасет с БД под Битрикс выключал, запускал встроенный тест битрикс - ноль на массу. Потом включил always - количество операций записи и изменения снизилось в 10 раз. Пул из двух nvme в зеркале

Он вообще коммиты с данными в бд тестит? Вопрос к бенчу

Он вообще коммиты с данными в бд тестит? Вопрос к бенчу

Я всегда к этому тесту относился с скептицизмом)Думаю, что тестит коммиты, не даром там отдельно параметры записи, чтения, изменения. А вообще для того, чтобы узнать, есть ли узкое место в хранилище, неплохим инструментом кажется pt-diskstats.

👆подкорректировал, а то написал так, что самому не всё понятно было

Господа, подскажите по теме тюнинга пула под MySQL. Можно ссылками на любом языке. Я что-то слышал про 8кБ блоки, но это не точно.

Господа, подскажите по теме тюнинга пула под MySQL. Можно ссылками на любом языке. Я что-то слышал про 8кБ блоки, но это не точно.

https://wiki.freebsd.org/ZFSTuningGuide#MySQL

https://wiki.freebsd.org/ZFSTuningGuide#MySQL

Такая себе инструкция. На гарантированную потерю данных, если нет защиты по питанию

Господа, подскажите по теме тюнинга пула под MySQL. Можно ссылками на любом языке. Я что-то слышал про 8кБ блоки, но это не точно.

8кб для постгреса, для MySQL - 16кб. zfs set primarycache=metadata tank/db zfs set atime=off tank/db zfs set recordsize=16k Это базовые настройки, подходящие для всех primarycache=metadata указывает кешировать в ОП на чтение только метаданные, так как у MySQL свой кеш в ОП есть, настраиваемый. Остальные думаю понятны без объяснений