Ключевое тут «до»

ну так рассчитывать надо на это, у меня сейчас «DDT entries 7709539, size 703B on disk, 227B in core»

В том то беда, что это единственный кейс где она даёт хороший эффект

На бэкапах Db2 с опцией dedup_device (в команде db2 backup) эффект колоссальный. Получается намного экономнее, чем db2 backup incremental.

На бэкапах Db2 с опцией dedup_device (в команде db2 backup) эффект колоссальный. Получается намного экономнее, чем db2 backup incremental.

db2 бекапит без сжатия?

db2 бекапит без сжатия?

Есть опция сжатия и шифрования, для dedup_device их использовать скорее всего бессмысленно. Да и потом ZFS сама неплохо сжимает.

Есть опция сжатия и шифрования, для dedup_device их использовать скорее всего бессмысленно. Да и потом ZFS сама неплохо сжимает.

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

*чем если рар на непожатый бекап

Вероятно СУБД использует более оптимальные фрагменты для сжатия, словарь соответственно и т.п.

Dedup дает намного большую экономию, чем сжатие.

С опцией Db2 dedup_device для баз данных, накапливающие учетные документы, ZFS становится как бы бездонной бочкой, которая всего в несколько раз может превышать объем базы, даже если бэкапить ежедневно. Но почистить такой dataset ZFS потом абсолютно нереально по крайне мере в старых версиях ZFS - попытка удаления файла завешивает сервак наглухо после нескольких часов обращений к пулу. Только zpool destroy.

Dedup дает намного большую экономию, чем сжатие.

это что у тебя за таки странные данные, на которых дедуп эффективнее сжатия?

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

это что у тебя за таки странные данные, на которых дедуп эффективнее сжатия?

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

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

вопрос в окне по которому это происходит

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

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

Так какая разница, что они делают внутренний dedup, внутри базы данные не очень то повторяются с учетом выравнивания страниц и т.п. А бэкапы с опцией dedup_device - это ювелирные дельты, как в send | receive.

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

база mssql, до перехода на новую версию скуля в котором появилось сжатие, занимало где-то 1.2тб, в арзиве раром - где-то 200-250. после появления встроенного - стала занимать 150-190гб

дедуп даст такой эффект?

т.е. прийдется лить базу без сжатия (иначе дедупа вообще не будет, один бит поменялся и весь архив будет другой) минусы - по сети летит в 10 раз больше данных

дедуп даст такой эффект?

Если база размером 1TB растет на 10 гиг в день, то каждый новый ПОЛНЫЙ бэкап Db2 с опцией dedup_device будет отъедать на ZFS со включенной дедупликацией примерно кратно 10 гигам, не скажу точно сколько. 15-20 гиг в день вероятно.

не факт что оно даст ту экономию что просто сжатие

Если база размером 1TB растет на 10 гиг в день, то каждый новый ПОЛНЫЙ бэкап Db2 с опцией dedup_device будет отъедать на ZFS со включенной дедупликацией примерно кратно 10 гигам, не скажу точно сколько. 15-20 гиг в день вероятно.

это называется incremental backup и работает отлично без дедупа

не факт что оно даст ту экономию что просто сжатие

Ну ты привел пример, сжатие дает на каждый бэкап 200 гиг, а дедуп раз в 10 меньше.

это называется incremental backup и работает отлично без дедупа

Если нет блобов, с блобами по крайне мере в Db2 инкремент почти не работает, получается 70-90% от полного.

Ну ты привел пример, сжатие дает на каждый бэкап 200 гиг, а дедуп раз в 10 меньше.

т.е. в итоге за 10 дней: 1.2тб база + 100гб изменений вместо 140гб база + 30гб инкрементов

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

т.е. в итоге за 10 дней: 1.2тб база + 100гб изменений вместо 140гб база + 30гб инкрементов

Я не спорю, что инкрементальные бэкапы MSSQL вероятно могут дать примерно такой же эффект как Db2 dedup_device.

ниче, вот "чиашники" доведут цены на винты до заоблачных высот и станет выгодно ставить память для дедупа)

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

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

ниче, вот "чиашники" доведут цены на винты до заоблачных высот и станет выгодно ставить память для дедупа)

Погоди, они еще в оперативу научатся копать.

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

на гигабите восстановление 1.2 тб занимает гдето 15 минут расчетно (в реальности 20-25), а 140 - минут 5-10

на гигабите восстановление 1.2 тб занимает гдето 15 минут расчетно (в реальности 20-25), а 140 - минут 5-10

А сколько сам бэкап, если online?

А сколько сам бэкап, если online?

я ж пишу: 1.2 тб без сжатия, 180гб при сжатии мсскл

По времени.

Создание полного online бэкапа 1Tb базы MSSQL сколько времени занимает?

И на каком оборудовании?

читает где то со скоростью 600-800мб/с

И на каком оборудовании?

G8, 170гб озу, raid10 samsung 860pro (4шт по 1тб)

У меня было намного медленнее оборудование, чтение от силы 100 Мб/c с кэшированием, а напрямую с диском и вовсе 50Мб/сек.

читает где то со скоростью 600-800мб/с

Все же интересно, сколько времени занимает бэкап по факту, без всех этих рассчетов.

читает где то со скоростью 600-800мб/с

Кстати гигабитная сетка ведь столько не прокачает.

Мсскуль локально читает

Мсскуль локально читает

Это понятно, потом жмет еще.

Все же интересно, сколько времени занимает бэкап по факту, без всех этих рассчетов.

Чуть позже гляну

А кстати если iSCSI, то для такого стоража нужна уже 10 гигабитная сетка.

Кстати гигабитная сетка ведь столько не прокачает.

Так потому и профит от сжатия

Так потому и профит от сжатия

Я к тому, что у меня хранилка была отдельно по iSCSI. И даже на гигабитной сети редко когда могла забить хотябы 80-90% канала.

А кстати если iSCSI, то для такого стоража нужна уже 10 гигабитная сетка.

Там локальные диски и сжатие на сетевые. Потому скорость 800 ужимается где-то до 80-90 мб по сети

У меня был такой конфиг: Хранилка ZFS zvol -> гигабитный iSCSI -> Db2 host -> гигабитная сетка до ZFS бэкапа.

У меня был такой конфиг: Хранилка ZFS zvol -> гигабитный iSCSI -> Db2 host -> гигабитная сетка до ZFS бэкапа.

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

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

Во первых это было не реализовать технически, не было подходящих дисков для сервера. Во вторых как бы оно стало быстрее работать на сервере, если на хранилке не выдавало больше 50мб/сек? Там было 4 HDD диска и пара SSD для кэширования.

HDD он хоть на самом мощном сервере работать быстрее не будет.

Во первых это было не реализовать технически, не было подходящих дисков для сервера. Во вторых как бы оно стало быстрее работать на сервере, если на хранилке не выдавало больше 50мб/сек? Там было 4 HDD диска и пара SSD для кэширования.

Хм. Это что за диски такие мрачные?

А кстати если iSCSI, то для такого стоража нужна уже 10 гигабитная сетка.

Не хватит

Оверхед процентов под 25-30

Хм. Это что за диски такие мрачные?

Seagate SAS но самые тормозные. Так любые HDD по IOPs недалеко ушли друг от друга.

Оверхед процентов под 25-30

От настроек ведь зависит? Размер блока и т.п.

Нет. Разве что от мту - но и там особо делу не помогает

Seagate SAS но самые тормозные. Так любые HDD по IOPs недалеко ушли друг от друга.

Ты же мб/с говоришь, при чем тут иопс

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

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

Ну почему - может быть и там.

Ты же мб/с говоришь, при чем тут иопс

СУБД вообще-то дает рандомную нагрузку. Наивно ожидать запросов на последовательное чтение, где каждый диск бы выдавал по 100-150 м/бс. Речь о загрузке канала на рандомной нагрузке.

Чуть быстрее будет отдаваться обработка ио

А с учетом задержек в эзернете с тцпип там тоже не особо много иопсов выжмешь

Чем файберченнел нравится - там ио пролетают очень быстро через транспорт

Ну почему - может быть и там.

В сети батарейка? Это что за реализауия такая?

В сети батарейка? Это что за реализауия такая?

Кеш на таргете

Чем файберченнел нравится - там ио пролетают очень быстро через транспорт

Надо будет потом попробовать другие варианты транспорта для iSCSI.

Сам таргет чуть быстрее отдаст ответ, чем без кеша

СУБД вообще-то дает рандомную нагрузку. Наивно ожидать запросов на последовательное чтение, где каждый диск бы выдавал по 100-150 м/бс. Речь о загрузке канала на рандомной нагрузке.

Субд обычно префетчит страницами и если большая часть горячих данных не в памяти, то начинается жопа

Надо будет потом попробовать другие варианты транспорта для iSCSI.

А вот нету - в самом айскази первая i - это интернет, насколько я помню

Если уж на то пошло можно играться с FCoIB

Кеш на таргете

Так толку, мы все равно упираемся в иопсы сети. Сколько там иопсов на запись у гигабита не помнишь?

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

На хранилке был L2ARC под 200 гиг, без него было вообще все очень грустно. На серваке Db2 всего 40 гиг рама. L2ARC давал кратный прирост скорости, несмотря на то, что буфер пулы были тщательно настроены на hit rate близкий к 100%

На хранилке был L2ARC под 200 гиг, без него было вообще все очень грустно. На серваке Db2 всего 40 гиг рама. L2ARC давал кратный прирост скорости, несмотря на то, что буфер пулы были тщательно настроены на hit rate близкий к 100%

Он не кеширует запись

Так толку, мы все равно упираемся в иопсы сети. Сколько там иопсов на запись у гигабита не помнишь?

Например, передача в одну сторону - надо смотреть таблицы - предположим, 0.25мсек. РТТ - 0.5 мсек. Делим 1000 мсек в секунде и получаем 2000 в одном потоке.

И все это без учета работ по инкапсуляции, обращения к дискам и тому подобного

Он не кеширует запись

А причем тут запись? Мы же чтение обсуждали. Для записи у меня был SLOG на SSD зеркале, и там же место для Db2 active logs.

Например, передача в одну сторону - надо смотреть таблицы - предположим, 0.25мсек. РТТ - 0.5 мсек. Делим 1000 мсек в секунде и получаем 2000 в одном потоке.

Если ничего не путаю, то обычно рейдконтроллеры где-то 5-10к иопсов умеют

У меня 140 выжимал

А причем тут запись? Мы же чтение обсуждали. Для записи у меня был SLOG на SSD зеркале, и там же место для Db2 active logs.

Что там читать, база в памяти должна сидеть большей частью