.

Уважаемые люди не забыли нопейсать, как у них был сконфигурирован ZIL?
Я бы предпочел, чтобы они тестировали в режиме sync=disabled, потому что только в таком режиме ZFS дает производительность, близкую к режиму sync=standard при использовании для ZIL нормального оборудования типа зеркала из enterprise PCI SSD.
Этого вероятно было бы достаточно, чтобы ZFS выиграла тест.

И да, нынешняя версия ZFS работает пошустрее двухлетней давности, и постоянно идут работы по повышению производительности.

Кроме того я предлагал поверх ZFS использовать ext3/4, что нивилирует некоторые особенности файловой системы ZFS и оставляет только ее транзакционную сущность на блочном уровне.

Добавим к этому еще и то, что активные логи DB2 можно перекинуть на другой пул из чистого enterprise SSD.
А активные логи для OLTP системы - это половина нагрузки, если не больше.

И еще очень важное преимущество: ZFS позволяет снэпшотить базу DB2 на ходу, не отключая приложения в режиме write suspend.
Такого вероятно ни в PG, ни в Мусикуле нету.

По вашей же ссылке есть коментарии несогласных с "уважаемыми экспердами":

Tobias

This benchmark really is not in favour of ZFS. It‘s best practise to have a separate SSD ZFS ZIL device to have good write performance.

This benchmark is doing two disk writes for every mysql write because the data is first written to the zfs intent log snd later to the real blocks in the filesystem – sinply to have the crashsafe durable semantics of zfs. No wonder writes are 50% slower with zfs than ext4.
February 17, 2018 at 4:18 am

Yves Trudeau

I do agree with you, a SLOG would have a big impact here. Let’s say Jervin is presenting a worse case scenario and even then, considering the benefits of using ZFS, the cost is not that high. I hope he’ll present results with a decent SLOG just to size the difference. Like you said, I often got close to twice as fast for write intensive workloads with a good SLOG device.
February 19, 2018 at 10:35 am
Jervin Real

Indeed, there is not dedicated log device in this test as it is only to demonstrate how much MySQL can get slower if you simply switch your existing hardware to ZFS from another filesystem like ZFS. We will cover more cases in future blog posts.

Siemargl,

А можно посмотреть change history этого фрюшного ZFS? Он вообще развивается?
Давно ли в нем фиксили хоть один баг или вносили какое-то улучшение?

Ну не fuse же конечно же?
Думаете ядро FreeBSD будет работать с OpenZFS сильно лучше, чем Linux из-за менеджера памяти?

А что тут такого, учитывая сколько профитов дает ZFS, как минимум: проверка целостности пула, сжатие, снэпшоты, репликация.
Вы забыли отдельное SSD зеркало под активные логи базы DB2 ;)



Мне и самому интересно, но по вашей ссылке в коментариях вроде бы как раз это и обсуждаетcя?
Причем кэширование получается тройное, а не двойное, потому что у ZFS 2 уровня.
Но на втором уровне (только для чтения) можно легко зарядить кэш на быстрых SSD размером с базу или половину базы.
К примеру база размером 1TB, пул размером 5-10TB, чтобы базе легко дышалось и не чувствовалась фрагментация из-за COW.
ZFS всегда нужно добавлять нового свободного места, если остается около 80%, если нет времени на дефраг через send | receive в другой пул. Но в таком конфиге легко добавить быстрый SSD кэш на 1TB - размером с базу.
В DB2 Community с лимитом на оперативку всего 16 Гиг двойное кэширование пойдет как раз на пользу.

У меня вот идея появилась, а нельзя ли pureScale использовать с одним рабочим узлом DB2 ? :)
Это наверно даже быстрее бы работало, чем DB2 ext4 -> iSCSI -> ZFS zvol на другом хосте хранилища с большим кэшем.
Вот а если вместо это сделать так: DB2 16GB RAM working node -> pureScale CF с 100 гигами оперативки ? :)

Вернее, если занято более 80%, соответственно когда остается свободного менее 20%, особенно при высокой фрагментации.

Вот тут: https://habr.com/ru/company/tensor/blog/553754/

Копия: http://www.freezepage.com/1619463133YOOBBBMOAK

подробно расписаны недостатки PostgreSQL для тяжелых enterprise приложений.

Интересно было бы узнать, как с аналогичными фичами обстоят дела в СУБД IBM DB2, все ли хорошо по сравнению с PostgreSQL?

От себя добавлю из опыта общения с админами PostgreSQL пару лет назад, по их словам они вынуждены заниматься постоянными ежемесячными и даже чаще апгрейдами версий PostgreSQL (причем полностью вручную, по их словам автоматизировать им это не удалось, автоматических операторов у них почему-то нет или они о них не знают), потому что разработчикам их приложений постоянно хочется все более нового функционала PG. Не знаю, как на это реагировать в контексте сравнения с DB2? Возможно раньше PostgreSQL был в роли сильно отстающего и догоняющего по функционалу?

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

DB2 в последних версиях позволяет апгрейдить свой кластер master-slave вообще без downtime?