Comments 38
Сферическое сравнение. На ZFS в FreeBSD fsync при записи вернёт факт записи из ARC. В linux на ext4 fsync будет дожидаться сброса на накопитель.
ARC имеет прямое отношение к записи, вся запись через него идёт. ZIL, собирает в лог все записи и досылает их на диск, прилетит fsync, он выставит для набора записей метку подтвердив транзакцию, вернув ответ в ARC, а уже ARC вернёт ответ fsync. И ZIL может вообще не использоваться для записи, асинхронно всё может лететь на накопитель сразу из ARC, ZIL же только метаданные фиксирует по умолчанию. А вообще надо у ТС спросить, что у него там в zfs get sync.
Не там где вас, очевидно же.
В случае sync — операция будет зафиксирована на диске, а уже потом вернется ответ (поведение по умолчанию sync=on). Так же доступны опции sync=off — когда sync фактически игнорируется и записи кладутся на диск группами транзакций и sync=always — когда каждая транзакция кладется на диск, без всяких sync.
ZIL со включенным sync дает преимущества асинхронной записи.
ZIL не фиксирует только метаданные
ZIL не служит для ускорения, наоборот он замедляет работу системы, он служит для надежности.
Ознакомьтесь для начала с этим: www.ixsystems.com/blog/o-slog-not-slog-best-configure-zfs-intent-log
И перестаньте читать рунет — он заполонен бредом относительно ZIL и sync в ZFS. Не верным переводом.
Зачем репостить, то что и так есть в документации?
И ZIL (по умолчанию, при sync=on) всегда синхронизирует только операции с метаданными, остальное по мере того, как ОС или ПО подёргает fsync и/или на основании настроек своего драйвера. И даже без ZIL ZFS поддерживает согласованное состояние данных -https://blogs.oracle.com/roch/nfs-and-zfs,-a-fine-combination:
"We note that, even without a ZIL, ZFS will always maintain a coherent local view of the on-disk state"
И ZIL не базовая часть ZFS, а вспомогательная для обеспечения надёжности записи и восстановления после сбоев, без ZIL ZFS может использоваться.
Перестаньте поучать.
Хороший материал 2
Однако возможно в вашем описании так же имеются не точности. Например, довольно важный факт, вынесенный из статьи: данные из ZIL никогда не читаются. (не перемещаются из ZIL в пул)
При штатной работе сервера (без аварий) записи попадают в пул из ОЗУ группами транзакций, независимо от того были ли они синхронными или асинхронными.
Т.е ZIL не собирает транзакции, не кэширует, и читается только во время аварии. В ZIL дублируются синхронные операции, и там остаются на случай аварии.
Меня сбили с толку (а вдруг не сбили, вдруг так и есть?) статьи в которых говорится, что в ZIL пишется ALL DATA:
(Пример 1)
By default, the short-term ZIL storage exists on the same hard disks as the long-term pool storage at the expense of all data being written to disk twice: once to the short-term ZIL and again across the long-term pool Источник
(Пример 2)
The ZFS Intent Log is a logging mechanism where all the of data to be written is stored, then later flushed as a transactional write. Источник
(Пример 3)
Иллюстрирует что при выключенном SYNC — ZIL просто переходит в RAM область.
«So, if that's the case, then what exactly is going on? Well, there actually resides a ZIL in RAM when you enable „sync=disabled“ on your dataset» Источник
Спасибо за терпение, и обсуждение, я проголосую за ваши комментарии!
"Однако возможно в вашем описании так же имеются не точности. Например, довольно важный факт, вынесенный из статьи: данные из ZIL никогда не читаются. (не перемещаются из ZIL в пул)"
Проявите ещё немного внимательности — я ни разу не утверждал, что из ZIL что-либо перемещается в пул. Такое возможно только в момент импорта пула или при принудительных операциях по откату транзакции.
На дефолтных настройках действительно дебиан будет самым медленным, центос середнячком, а фрибсда самой быстрой.
Если известны все нужные пакеты, их версии и есть аналоги в портах фрибсды — лучше брать её. Если нет в портах, но есть в центосе — тогда его. А если неизвестно что в итоге нужно получить и нет уверенности в версиях — тогда дебиан. Разогнать его под определенную задачу легче, чем центос и фрибсду.
Мне редко встречаются проекты с утвержденным набором ПО и версий. Обычно задача стоит найти оптимальную комбинацию по отношению цена/качество. Поэтому стандартно ставим дебиан, а затем докручиваем настройки до предела.
Какой вывод из статьи — зфс лучше чем mdadm :)
Надо было тестировать фрю на ufs и линукс на ext4 или xfs
Какое-то странноватое тестирование…
Почему 4 из 5 ОС — Linux дистрибутивы? Почему нет Windows и Solaris, к примеру?
Почему не указаны архитектуры openSUSE и Ubuntu?
Предположу, что большое влияние на быстродействие может оказывать glibc. По сути — это сравнение именно её производительности. Ну и версии ядер конечно же тоже могут играть роль.
Почему не указаны архитектуры openSUSE и Ubuntu?
Написано, что все ОС 64-битные
По поводу производительности — скорее всего здесь ключевая роль у файловых систем и работа ядра ОС с этими фс
Ещё два раза прочёл статью наискосок. Не заметил что где-то написано что все ОС 64-битные. Можете процитировать?
Кстати, позвольте придраться, я спрашивал про архитектуру, а не про разрядность процессора.
Но тестирование всё-равно считаю странным. Остальные претензии в том сообщении на которое вы ответили.
По поводу Solaris тут вообще все очень просто
www.postgresql.org/download/solaris
Packages for Solaris 10 and 11 are available for Sparc and i386 platforms.
Although produced by Oracle (previously Sun), these packages are not officially supported by them.
То есть поддерживаются только спарки или устаревшая 386 платформа, и то у них нет официальной поддержки Oracle
www.postgresql.org/ftp/binary/v12beta2/solaris/solaris11/i386
www.postgresql.org/ftp/source/v12beta2
i386 — это базовая архитектура.
Так же посмотрите в исходники, а именно в файл INSTALL. Вы найдёте там ни одно упоминание о ОС Solaris, последняя версия которой датирована 2018-м годом. Версия PostgreSQL датирована 2019-м.
Ваша же цитата относится к «бинарникам». Т.е. к brebuild binaries.
С дефолтными настройками ОС вообще это сравнение лишено смысла. Допустим, мы внутри периметра корпоративной сети, доступ к серверу ограничен. Нужен нам selinux? Нужны нам патчи от spectre и прочие pti? Как настроена файловая система — например, отношение размера блока к размеру аппаратного блока? Короче это тест дефолтных настроек дистрибутивов, не более.
… а еще в центос 7 есть профили производительности. По-умолчанию — balanced, который реально никто использовать не будет. Ну, этот как пример… А ещё все вообще СУБД не любят гипертридинга и турбобуста, особенно на больших выборках, которые хорошо распараллеливаются. С этими настройками — одинаково всё? Если нет, то многое зависит от планировщика, который тоже можно переключить. Как и io scheduler...
Насколько я помню старые бенчмарки PostgreSQL, FreeBSD c UFS показывают примерно равные результаты с Linux c EXT3, от которых чуть отстает Linux c XFS. LVM дает просадку по производительности примерно равную ZFS. За приятные фичи приходится платить.
2) сжатие внутри бд и внутри файловой системы — это разные вещи разные уровни. Чтобы это понять, нужно представлять как работает любая COW файловая система. Файлы в ней не представляют собой «кусок диска» который был изначально захвачен базой (при последовательном доступе к диску). Copy-on-Write пишет в свободные блоки (в другое место на диске) при ЛЮБОМ изменении части исходных файлов (блоков).
2) cow и внутриблочное сжатие не имеют ничего общего. COW прекрасная вещь для снапшотов и клонов (что очень удобно для организации нескольких записываемых(!) дев-копий продакшен базы). Но если у вас нет снапшотов, то и COW нет. Вернее, исходный блок будет помечен в метаданных свободным сразу после записи нового, если счетчик его использования в снапшотах = 0. И таки да, эта особенность записи скорее всего и дает падение производительности баз данных на ZFS
TOAST работает только на колонках c storage EXTENDED, используется когда вы знаете, что там будут лежать сжимаемые данные. Например текстовые документы размером больше 2кб. Это куда более предсказуемая и управляемая конструкция, чем дедупликация и сжатие на уровне хранилища.
Он надеялся что постгри не живет с каким то конкретно дистрибутивом в ладах?
По сути он оттестировал быстродействие обмена с дисками в разных дистрибутивах Linux, еще и с дефолтными установками.
Времени судя по описанию у него было немало свободного.
В идеале нужно приложить график fio который будет аналогичным, его можно минут за 15 получить не заморачиваясь особо.
Последний раз я такие тесты видел (и сам делал) в конце нулевых. Ностальгии пост :)
А теперь по делу.
Интересно, дождался ли автор, пока linux soft raid проинициализирует весь рейд?
Минус soft raid в linux — он его инициализирует после создания, т.е. проходится по всем дискам. Естественно, это занимает быстродействие диска. В sysctl есть ручки для управления максимальной скоростью проверки. По умолчанию это 200 МБ/с, т.е. на старте диски несколько нагружены. И лучше дождаться окончания. Если что, это можно проверить в файле /proc/mdstat.
ZFS — это система, которая очень агрессивно кеширует в память. Отсюда и хорошие показатели скорости записи. Фактически, автор писал в оперативку и такой "ой, как все летает" :) Сами создатели ZFS подтверждают, что запись кешируется и сразу говорят "если хотите ZFS, просто ставьте ИБП". Надеюсь, у автора стоит ИБП :)
Ещё нужно признать, что у ZFS действительно шикарная система кеширования горячих данных. ARC и L2 ARC (adaptive read cache) — шикарные штуки. По хорошему, с ZFS нужно было сравнивать не просто linux, а linux с настроенной системой кеширования flashcache/bcache/dm-cache. А иначе это как сравнивать машины с N2O ускорением и без.
И из не технического.
Не думаю, что в 2019 кто-то будет менять ОС на FreeBSD ради таких показателей. Потому что, нужно посмотреть на ситуацию шире.
Если у вас действительно такая нагрузка на сервере на запись (может 1С на крупном предприятии), то у вас хватит денег сделать кластер и масштабироваться горизонтально. И посадить спецов и консультантов закрутить настройки тюнинга.
А если нагрузка есть, а денег нет (стартап, например), надо что-то менять в бекенде :) Ибо нагрузка может вырасти ещё, а железо уже не потянет. В 2-3 раза больше пользователей и все ляжет.
Потом, другая ОС в инфраструктуре — это расходы на управление.
Уже давно настала мода на автоматическое управление конфигурацией сервера силами ansible/salt/chef/puppet.
И когда все написано под linux, впихнуть туда FreeBSD — тот ещё гемор.
А если не впихивать — гемор ещё больший (ручками заводить юзеров, раскатывать пакеты, править конфиги, бекапить их).
Потом, по хорошему, основная нагрузка на базу должна быть именно на чтение. А тут у Linux все хорошо :)
Кстати говоря, double write buffer в InnoDB рекомендуют отключать как раз по причине того, что этот функционал дублируется в ZFS
Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE