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

чуть чуть но хуже

а у вас получается что зстд жмет лучше рара (не про скорость

ещё неправильно сравнивать результаты сжатия на разных данных

раньше мы жали 7z, было ещё меньше, но это уже совсем оффтоп )

раньше мы жали 7z, было ещё меньше, но это уже совсем оффтоп )

в это верю. но при варианте "бекап по сети" - самый шустрый будет сжатие средствами скл. никакой зфс не исправит ограничение скорости сети

у нас там 25G )))

а бэкап идёт на скорости под гигабайт в секунду

у нас там 25G )))

жирно :)

так что никакого ограничения сети, запас раза в три есть

хотя где 25ж, там и стор должен должен давать хотя бы 10гб/с )

у нас там 25G )))

25 вроде бы ощутимо дешевле 40 кстати?

не знаю, честно говоря, мы как-то пропустили 40

Ну несколько раз слышал, что оптимально, если 10 нехватает, а 40 - жирно и много

ну 40 — это же 4x10, dac шибко толстые, qsfp вместо sfp и всё такое

сжал несжатый бекап sql со сжатием по умолчанию (-3), но единым файлом. получилось 100 гигов. против, напомню, 149 гигов сжатого бэкапа ms sql

Что-то кажется, что это не те объёмы, из-за которых имеет смысл так заморачиваться :)

ну как сказать, это одна база, полные бэкапы идут каждую ночь

плюс, что немаловажно, восстановление из несжатого бэкапа идёт быстрее, чем из сжатого

«так заморачиваться» это сказать zfs set compression=zstd-5 и добавить @Compress = 'N', к параметрам бэкапа в ms sql

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

«так заморачиваться» это сказать zfs set compression=zstd-5 и добавить @Compress = 'N', к параметрам бэкапа в ms sql

А меня обсмеяли в девопс чатике, начали втирать какую-то хрень про то, что сжатие отъедает проц и т.п., впечатление народ только что из 90х попал сюда, при этом меня называют хрычом :) "Мы мол из-за тебя чуть не попробовали твою ZFS, хорошо, что не попробовали, а то бы наши данные пострадали. " "Интеллект" из них так и прет прям.

ну конечно отъедает

А меня обсмеяли в девопс чатике, начали втирать какую-то хрень про то, что сжатие отъедает проц и т.п., впечатление народ только что из 90х попал сюда, при этом меня называют хрычом :) "Мы мол из-за тебя чуть не попробовали твою ZFS, хорошо, что не попробовали, а то бы наши данные пострадали. " "Интеллект" из них так и прет прям.

ссылочку на обсуждение можно?

если проц — узкое место, а объёмы дискового io велики, то не стоит включать сжатие

ну конечно отъедает

Особенно если сравнить с пропускной способностью дисковой подсистемы :)

ссылочку на обсуждение можно?

Они тот чатик покоцали уже, но хистори у меня есть в TG HTML.

если проц — узкое место, а объёмы дискового io велики, то не стоит включать сжатие

На современном оборудовании обычно наоборот.

Они тот чатик покоцали уже, но хистори у меня есть в TG HTML.

тогда не нужно. Я думал что это что-то свежее

тогда не нужно. Я думал что это что-то свежее

Месяц назад примерно.

Месяц назад примерно.

и что за чат?

и что за чат?

DevOps альтернативный, для тех, кого забанили в DevOps_ru Мне там некий Сергей кажется Пузырев (вероятно виртуал) заявил, что я вообще ничего не умею и не знаю.

если проц — узкое место, а объёмы дискового io велики, то не стоит включать сжатие

Подтверждаю. Даже на топовом оборудовании

Подтверждаю. Даже на топовом оборудовании

Так щас же обычно по 30-60 ядер. А дисковая в ПФР отродясь была никакая, всегда ждали хранилищ как горячих пирожков.

Так щас же обычно по 30-60 ядер. А дисковая в ПФР отродясь была никакая, всегда ждали хранилищ как горячих пирожков.

Лейтенси:)

Лейтенси:)

Не, ну если у вас пропускной и места на дисках до дури, сплошные скоростные SSD, то может быть вы в каких-то случаях и правы. Но при использовании HDD, сжатие FS - MUST HAVE! Кроме того современные СУБД поддерживают multi temperature.

Не, ну если у вас пропускной и места на дисках до дури, сплошные скоростные SSD, то может быть вы в каких-то случаях и правы. Но при использовании HDD, сжатие FS - MUST HAVE! Кроме того современные СУБД поддерживают multi temperature.

Вот я про ссд и говорил как раз. С хдд сжатие не тестировал - но не думаю, что там ситуация драматически отличается

Лейтенси:)

а что latency?

а что latency?

Взлетает на порядок-два

При десятках иопс это вполне возможно даже на топовом:)

Вот я про ссд и говорил как раз. С хдд сжатие не тестировал - но не думаю, что там ситуация драматически отличается

А как же не отличаться, если там всего по 150-300 IOPS на диск? Тут хоть позапрошлогодний проц ставь, всяко будет ОГРОМНЫЙ выигрыш.

не думаю, что на hdd она вырастет

А как же не отличаться, если там всего по 150-300 IOPS на диск? Тут хоть позапрошлогодний проц ставь, всяко будет ОГРОМНЫЙ выигрыш.

Не тестировал :)

не думаю, что на hdd она вырастет

Ну там то да. Порядки другие. 😁

не думаю, что на hdd она вырастет

Головы то у HDD елозят во МНОГО МИЛЛИОНОВ раз медленнее, чем бегают электроны в p-n переходах ЦПУ, однако. И ессно все это сдабривается скоростным SSD кэшем.

DevOps альтернативный, для тех, кого забанили в DevOps_ru Мне там некий Сергей кажется Пузырев (вероятно виртуал) заявил, что я вообще ничего не умею и не знаю.

ух ты. альтернативные девопсы))) я даже не предполагал о таком. в общем чате zfs вообще не обсуждали на моей памяти

Которые транк бейзд девелопмент внедряют?)))

плюс, что немаловажно, восстановление из несжатого бэкапа идёт быстрее, чем из сжатого

вот не факт. сильно не факт. процессоры сейчас сильно быстрее чем диски

ух ты. альтернативные девопсы))) я даже не предполагал о таком. в общем чате zfs вообще не обсуждали на моей памяти

У них остался сайт работудатилей: devops_jobs_ru А раньше еще был технический, почему-то удалили его как раз после того, как я с ними разосрался там :) Напихал им ссылок про ZOG, спецслужбы, закладки и т.п., меня побанили нафик, а чатик снесли почти сразу. Хорошо хоть в дурку не отправили.

У них остался сайт работудатилей: devops_jobs_ru А раньше еще был технический, почему-то удалили его как раз после того, как я с ними разосрался там :) Напихал им ссылок про ZOG, спецслужбы, закладки и т.п., меня побанили нафик, а чатик снесли почти сразу. Хорошо хоть в дурку не отправили.

может просто тебя там забанили, а чат на месте

Сюда тоже не надо такого кидать :)

может просто тебя там забанили, а чат на месте

Я обращался к чатовладельцу, он давал ссылку, кроме него в чате никого нет.

Я обращался к чатовладельцу, он давал ссылку, кроме него в чате никого нет.

это он нафотошопил. опасно с вами дело иметь)))

Ну вероятно в копии лога чата тоже есть адрес чата, лень сверять.

Взлетает на порядок-два

вот сейчас как раз было немного свободного места на nvme, создал пул, проверил чтени/запись в один поток — значимой разницы не вижу

вот сейчас как раз было немного свободного места на nvme, создал пул, проверил чтени/запись в один поток — значимой разницы не вижу

Ну один поток так и так не заполнит ресурсы

а в реальной жизни у вас есть столько io, чтобы загрузить все ядра?

Ресурсы имел ввиду технологический потолок ио для текущей конфигурации

а зачем он мне?

а в реальной жизни у вас есть столько io, чтобы загрузить все ядра?

В реальной жизни оллфлеш на котором эксплуатация как-то воткнула компрессию :)

речь про схд?

Ага. В случае с зфс- сжатие - дополнительное приседание, которое так и так прибавит задержек. Если не изменяет память, фио на тестах с хдд и сжатием ухудшило показатели, посему в одном из внедрений я сжатие и не включал (хотя хотел).

ну вот сейчас я не вижу особой разницы

В общем тогда я его не включал аргументированно

ну вот сейчас я не вижу особой разницы

А нагоните потоков 64

Можно для полноты картины кеши отключить на этом пуле

И смотреть на метрику задержки, а не общую скорость. И данные бы не только нули и ff:)

. write: IOPS=10.3k, BW=40.1MiB/s (42.0MB/s)(1202MiB/30001msec); 0 zone resets write: IOPS=7283, BW=28.5MiB/s (29.8MB/s)(854MiB/30001msec); 0 zone resets write: IOPS=16.6k, BW=64.7MiB/s (67.8MB/s)(1940MiB/30001msec); 0 zone resets

угадайте что где )

И смотреть на метрику задержки, а не общую скорость. И данные бы не только нули и ff:)

а какая разница?

а какая разница?

В олтп например разница ощущается

гхм…

это одни и те же цифры

IOPS=QD/latency

Фио умеет распределение. Там может быть заметно

В общем, в обоих моих кейсах сжатие проявило себя зловредно с точки зрения отзывчивости :)

. lat (usec) : 2=0.01%, 250=0.01%, 500=0.32%, 750=2.11%, 1000=1.98% lat (msec) : 2=11.99%, 4=17.99%, 10=51.80%, 20=13.06%, 50=0.53% lat (msec) : 100=0.09%, 250=0.10%, 500=0.02% lat (usec) : 2=0.01%, 50=0.01%, 250=0.01%, 500=4.05%, 750=7.61% lat (usec) : 1000=4.23% lat (msec) : 2=7.66%, 4=13.73%, 10=44.43%, 20=13.47%, 50=3.22% lat (msec) : 100=0.72%, 250=0.75%, 500=0.08%, 750=0.03%, 1000=0.01% lat (usec) : 10=0.01%, 500=2.77%, 750=7.18%, 1000=7.29% lat (msec) : 2=22.24%, 4=25.36%, 10=31.49%, 20=2.86%, 50=0.58% lat (msec) : 100=0.18%, 250=0.04%

ну так что где? в этих тестах? )))

я никакой разницы «на 1-2 порядка» не вижу

Нагрузки разные у нас, видимо