Дедуп очень специфичен и нужен только для одинаковых данных

Дедуп очень специфичен и нужен только для одинаковых данных

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

в общем я лично для себя решил что дедупликация мне не нужна))

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

Нафига тут дедуп, если слои можно кэшировать?)

Нафига тут дедуп, если слои можно кэшировать?)

контейнер - не всегда докер

Нафига тут дедуп, если слои можно кэшировать?)

а я дедуп включал не конкретно под докеры

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

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

Дедуп как стадия взрсления: все проходят через нее Пока не появится офлайн версия дедупа, он нафиг не нужен

он мне на самом деле не то чтобы и нужен был, я просто хотел протестирвоать фичу и забыл выключить её))

охренел от аткого наказания)))

он мне на самом деле не то чтобы и нужен был, я просто хотел протестирвоать фичу и забыл выключить её))

Так проблема дедупа: он не выключается брал дропа пула))

Так проблема дедупа: он не выключается брал дропа пула))

как же я тогда его выключил))

ещё как выключается

zfs set

как же я тогда его выключил))

Только таблицы в памяти все равно остались)))

Только таблицы в памяти все равно остались)))

да, но новые не вычисляются

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

с таким же успехом можно сказать что сжатие нельязв ыключить

сжатые данные то остались

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

Это не документировано, не скажу

Это не документировано, не скажу

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

с таким же успехом можно сказать что сжатие нельязв ыключить

Сжатие память для работы не жрет. А таблицы жрут

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

Да, запись стала без таблиц, но чтение все равно по таблицам

Сжатие память для работы не жрет. А таблицы жрут

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

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

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

Любое чтение ж через них по идее. Хотя возможно ошибаюсь

Любое чтение ж через них по идее. Хотя возможно ошибаюсь

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

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

вот и я так думал)

кстати про сжатие. оно имеет смысл на быстрых нвме ссд?

в смысле не станет ли оно основным тормозом?

кстати про сжатие. оно имеет смысл на быстрых нвме ссд?

lzo в теории не должно, было бы полезно если был тест для проверки у себя сжатия, но таких не нашел

станет, скорее всего

на 20-30к иопсов становилось

Ребят, zfs+kvm. Почему zvol volblocksize рекомендуется 4K, соотвественно page size гостя. При этом для dataset recordsize (128к default) рекомендуеся тюнить под workload, в духе 16к под базу, и больше под другие задачи. Но ведь гость в qcow2 будет по прежнему иметь page size 4k. В чем прикол?

Ребят, zfs+kvm. Почему zvol volblocksize рекомендуется 4K, соотвественно page size гостя. При этом для dataset recordsize (128к default) рекомендуеся тюнить под workload, в духе 16к под базу, и больше под другие задачи. Но ведь гость в qcow2 будет по прежнему иметь page size 4k. В чем прикол?

зачем на zfs держать qcow2 как файл в filesystem? CoW in CoW?

зачем на zfs держать qcow2 как файл в filesystem? CoW in CoW?

А какой бест практикс?)

А какой бест практикс?)

на zfs не использовать qcow2, а размещать гостей в zvol. С нужным размером блока (как например в Proxmox дефолтный blocksize=8k). Или 16к, если очень хочется разместить СУБД внутри ВМки (хотя я против такого), для СУБД как раз лучше подходит контейнер в filesystem с recsize требуемого размера

вчитался в zfs perf tuning, 4k для обоих recordsize/volblocksize. Чтобы соотвествовало пейджсайзу

кстати прокс как делает? на каждого гостя по zvol или все вмки в датасете? ну если прокс на одном хосте.

кстати прокс как делает? на каждого гостя по zvol или все вмки в датасете? ну если прокс на одном хосте.

на каждого гостя свой zvol

вчитался в zfs perf tuning, 4k для обоих recordsize/volblocksize. Чтобы соотвествовало пейджсайзу

4к - для обычной ОС может и нормально. Но если кто-то размещает тот же Постгрес, то это будет мало , у ПГ - 8к. А основной объём записи придётся именно на Постгрес

бот не разрешил линк на Джима Салтера запостить. Но вообщем zvol vs qcow это спорно. я за прометеус переживаю, там 1-2 байта на точку…

бот не разрешил линк на Джима Салтера запостить. Но вообщем zvol vs qcow это спорно. я за прометеус переживаю, там 1-2 байта на точку…

зачем на CoW ФС держаеть ещё одну CoW ФС? чем больше слоёв у бутерброда - тем он медленнее

бенчмарки проводили?

Внутри ВМ, которая на qcow, лежащая как файл на ZFS - ни разу. Внутри ВМки на zvol, да - делал. Буду очень сильно удивлён если первый вариант окажется быстрее

Салтер утвердждает что таки быстрее, если выполнен тюнинг под ворклоад. jrs-s net /2018/03/13/zvol-vs-qcow2-with-kvm/

Салтер утвердждает что таки быстрее, если выполнен тюнинг под ворклоад. jrs-s net /2018/03/13/zvol-vs-qcow2-with-kvm/

судя по треду, где участвует автор: https://www.reddit.com/r/zfs/comments/846hok/benchmarking_zvol_vs_qcow2_with_kvm/ он тестировал на ВМ, с cache=writeback. Я бы поостерёгся это использовать на ВМ с критичными данными. Да и если почитать тред полностью, то там дальше есть другой тест (в котором тоже участвует JRS) https://www.reddit.com/r/zfs/comments/86khhr/benchmarking_raw_image_vs_qcow2_vs_zvol_with_kvm/ где результаты уже практически 1 в 1. ну и я бы учитывал что за 3 года ZFS сделала в своём развитии много больше чем QCOW. Так что тесты нужно проводить заново)

Нет ничего плохого в writeback. Для критических данных делают кластеризацию на уровне приложения (хотя если много денег то можно и на уровне виртуалки сделать fault-tolerance, но это не cloud-native.) Но вот и я про то что надо тестировать, а не бросаться голословно.

Нет ничего плохого в writeback. Для критических данных делают кластеризацию на уровне приложения (хотя если много денег то можно и на уровне виртуалки сделать fault-tolerance, но это не cloud-native.) Но вот и я про то что надо тестировать, а не бросаться голословно.

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

врайтбек опасен тем, что в какой-то момент он захочет сфлюшить всё, и весь ио встанет.

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

я говорю только про софтовый врайтбек - в аппаратном от второго есть защита.

Нет ничего плохого в writeback. Для критических данных делают кластеризацию на уровне приложения (хотя если много денег то можно и на уровне виртуалки сделать fault-tolerance, но это не cloud-native.) Но вот и я про то что надо тестировать, а не бросаться голословно.

вот послушает вас кто-нибудь, и включит на виртуалке с Постгресом врайтбэк. До первого крэша ядра или железа. А потом будет долго думать как быстро сможет восстановить бэкап и найдёт утерянные данные между текущим временем и временем бэкапа. Но подход - всё переводим на врайтбэк, обвешиваемся репликами и бэкапами каждый час - наверное тоже имеет для кого-то смысл. Вопрос только в расходах на поддержание всего этого.....

ага. тут надо уже у бизнеса интересоваться пограничными моментами.

и врайтбек - это огромное расходование рамы, иначе он будет не быстрее, чем обычное синхронное обращение к дискам.

вот послушает вас кто-нибудь, и включит на виртуалке с Постгресом врайтбэк. До первого крэша ядра или железа. А потом будет долго думать как быстро сможет восстановить бэкап и найдёт утерянные данные между текущим временем и временем бэкапа. Но подход - всё переводим на врайтбэк, обвешиваемся репликами и бэкапами каждый час - наверное тоже имеет для кого-то смысл. Вопрос только в расходах на поддержание всего этого.....

не лучше лишнюю память в пг отдать ?

не лучше лишнюю память в пг отдать ?

может и лучше. И вообще ПГ внутри ВМ стараться не держать если есть возможность)

да нормально он там живёт.

если настроен с умом

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

можно подробней. тесты, замеры, issue ?

вот послушает вас кто-нибудь, и включит на виртуалке с Постгресом врайтбэк. До первого крэша ядра или железа. А потом будет долго думать как быстро сможет восстановить бэкап и найдёт утерянные данные между текущим временем и временем бэкапа. Но подход - всё переводим на врайтбэк, обвешиваемся репликами и бэкапами каждый час - наверное тоже имеет для кого-то смысл. Вопрос только в расходах на поддержание всего этого.....

господа, вы предвзяты. В cache=none тоже нет ничего плохого, как и в writeback. Везде исходим от задач и ворклоада. А то влепить на хост дефолтный xfs(оффтоп) и поставить cache=none, а потом удивляться паникам от фрагментации это тоже класс? Под штуки класса прометеус writeback самое то, для баз, конечно, уже нюансы.

в случае ZFS есть же арк кеш, которого мне пока с головой, кеширование на уровне kvm мне чёт не зашло

зачем создавать ещё один слой

Кто-нибудь знает минусы использования ZFS под хранение баз мускуля?

Кто-нибудь знает минусы использования ZFS под хранение баз мускуля?

Минусов нет, cloudflare использует и есть от них гайд по настройке

вот послушает вас кто-нибудь, и включит на виртуалке с Постгресом врайтбэк. До первого крэша ядра или железа. А потом будет долго думать как быстро сможет восстановить бэкап и найдёт утерянные данные между текущим временем и временем бэкапа. Но подход - всё переводим на врайтбэк, обвешиваемся репликами и бэкапами каждый час - наверное тоже имеет для кого-то смысл. Вопрос только в расходах на поддержание всего этого.....

15 минут, можно и потерять :)

Кто-нибудь знает минусы использования ZFS под хранение баз мускуля?

кроме того что зфс тормоз? никаких )

кроме того что зфс тормоз? никаких )

вот только почему у меня на ZFS мускуль работает живее чем на ext4)), потому что она тормоз?))

можно подробней. тесты, замеры, issue ?

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

вот только почему у меня на ZFS мускуль работает живее чем на ext4)), потому что она тормоз?))

видимо Вы не умеете ext4 готовить) зы: были версии virtual box на которых мускл работал быстрее чем на чистом железе... потом оказалось, что они игнорят команду флеш буферс)

видимо Вы не умеете ext4 готовить) зы: были версии virtual box на которых мускл работал быстрее чем на чистом железе... потом оказалось, что они игнорят команду флеш буферс)

Смешно, готовить екст4, лол. Видимо ты её умеешь готовить zfs

Смешно, готовить екст4, лол. Видимо ты её умеешь готовить zfs

а что его готовить? выравнять ashift и дофига памяти. дофига памяти . дофига памяти . дофига памяти и все равно он будет тормозить. можно sync выключить и atime, будет тормозить меньше, но будет. можно добавить ssd для лога и ссд для кеша чтения. будет тормозить меньше.. возможно (у меня 180гб ссд на 14тб, папдания в кеш мизерные, а если синк выключен, то лог на ссд понту пихать нет)

вы же sync=enable гоняете? :)

а что его готовить? выравнять ashift и дофига памяти. дофига памяти . дофига памяти . дофига памяти и все равно он будет тормозить. можно sync выключить и atime, будет тормозить меньше, но будет. можно добавить ssd для лога и ссд для кеша чтения. будет тормозить меньше.. возможно (у меня 180гб ссд на 14тб, папдания в кеш мизерные, а если синк выключен, то лог на ссд понту пихать нет)

Ой лол

Попадания в кеш

Чивооо

Я вырубаю арк кеш для волюма с мускулем

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