Zfs on linux performance

Copy raw contents

Внимание! Данная тема регулярно служит источником холиваров и граблей! Рекомендуется читать до конца перед применением!

Зачем вот это вот все

Postgres, в отличие от MS SQL, не умеет сжатие данных.
Зато сжатие отлично умеет zfs, файловая система и по совместительству менеджер хранилищ.
TODO: COW — кратко плюсы и минусы
Аналоги: btrfs, почему все же не она.
Большое сравнение файловых систем смотрим здесь.

Что не так с zfs

Как считают многие linux-разработчики и ментейнеры дистрибутивов, «проект мог бы быть прекрасен и мог бы претендовать на роль лучшей ФС будущего», но имеет несовместимую с ядром linux лицензиюю. В общем, лицензионные перипетии ужасно изговняли всю эту историю, и это очень-очень печально (за подробностями — в google). Несмотря на это, debian, ubuntu, arch, suse и другие дистрибутивы не только поддерживают zfs, но и имеют воможность установки системы на zfs. Если хочется zfs прям из коробки, например для создания обособленного хранилища, имеет смысл посмотреть в сторону freebsd. Небольшой курьез — в виду очень бодрого развития проекта zfs-on-linux freebsd планирует пересесть на него

Важно! Неоптимальная конфигурация пула zfs может снизить быстродействие на порядок!
Чтобы понять, насколько велика может быть разница, имеет смысл сделать хотя бы сферические замеры на ext4, а затем повторить их на zfs. Самый простой, хоть и не самый лучший, способ — создать раздел ext4 и выполнить dd с разным размером блока. Предположим у нас есть диск /dev/sdb, на который мы планируем положить zfs.
Для начала форматируем его в ext4:

/test mount /dev/sdb1

TODO: такой замер оказался ни о чем, сделать отсюда
Результаты записываем и после создания тома zfs тесты повторяем. Практически все параметры томов zfs можно менять на лету: очень рекомендую попробовать поставить recordsize равным 4, 8, 16, 32, 64, 128k и сравнить результаты замеров. Так, при блоке 128k скорость записи примерно уравнивается с показателями ext4. Задрежки, конечно, при таких условиях будут несколько больше.
Также можно сравнить производительность без сжатия, ну и сдругими параметрами поиграть.
Кратко общие рекомендации в интернетах: если надо писать большие файлы, либо писать много потоком — ставим 128k, много мелких файлов или сильно непоследовательно — в районе 4-16k. Оптимальное значение подбираем опытным путем.
Рекомендации в интернетах для postgresql: имеет смысл ставить размер записи равным (или большим) размеру блока, записываемого СУБД, в случае postgresql это 8k.

Рекомендации от сердца, выстраданные в результате долгих экспериментов и последующих наблюдений в проде:

Ставить 128k и не париться. Оно так по-умолчанию и стоит, к слову 😉
Сжатие lz4 обязательно, ибо по факту одни плюсы в выхлопе, минусов ни одного найти не удалось
Использовать zfs на гипервизоре для размещения виртуалок, в виртуалках использовать ext4
Избегать «вложенности» в случае виртуальных машин, когда zfs на гипервизоре и zfs в виртуалке
Для БД идеальной получилась схема с размещением на гипервизоре proxmox в lxc-контейнере, контейнер размещен на zfs — быстродействие сопоставимо с работой на хосте в пределах погрешностей

sync: Про sync настоятельно рекомендую все изучить и взвесить самостоятельно. Если кратко, то в случае внезапно краха системы ФС останется абсолютно живой и здоровой (хвала COW), но будет потеряно до 30 секунд работы (как правило 2-5, получено путем примерно 100 экспериментов с жестким отключением питания на обычном ПК). В случае БД теоретически можно получить несогласованные записи (например документ есть, а движений нет), но на практике еще я лично не сталкивался. Лично я для себя принял решение ставить sync=disabled.

Ну и напоследок про бэкапы. Ну их ведь все и всегда регулярно делают и проверяют, да? Мы вот еще и реплики всех виртуалок и контейнеров держим, для особо важных данных — еще и не по одной, благо дисковое пространство сегодня дешево.

Установка и создание пула

Создание пула для postgresql:

«/dev/» — здесь может быть диск или раздел диска (посмотреть, что есть: ls /dev/sd*), или просто каталог в случае тестов, например

/zfstst.
Если пул создется на hdd, и есть немного места на ssd, можно на ssd создать раздел и включить его в пул в качестве кэша:

Устанавливаем и сразу проверяем параметры:

Ограничение потребления памяти

Создаем /etc/modprobe.d/zfs.conf, в него записываем:

Отключение «умного» кэширования (только при необходимости, например на хосте proxmox):

Затем обновляем initramfs:

Чтобы не ждать перезагрузку, можно менять параметры на лету. Например:

Установка debian на zfs

Параметры: cat /sys/module/zfs/parameters/PARAMETER
Статистика ARC: cat /proc/spl/kstat/zfs/arcstats
iostat: zpool iostat -v

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

ZFS on Linux: вести с полей 2017

Проект ZFS on Linux изначально был создан для портирования существующего кода из Solaris. После закрытия его исходного кода совместно с сообществом OpenZFS проект продолжил разработку ZFS для Linux. Код может быть собран как в составе ядра, так и в виде модуля.

Сейчас пользователь может создать пул с последней совместимой с Solaris версией 28, а также с приоритетной для OpenZFS версией 5000, после которого началось применение feature flags (функциональные флаги). Они позволяют создавать пулы, которые будут поддерживаться в FreeBSD, пост-Sun Solaris ОС, Linux и OSX вне зависимости от различий реализаций.

В 2016 году был преодолён последний рубеж, сдерживавший ZFS на Linux — многие дистрибутивы включили его в штатные репозитории, а проект Proxmox уже включает его в базовую поставку. Ура, товарищи!

Рассмотрим как наиболее важные отличия, так и подводные камни, которые есть в настоящее время в версии ZFS on Linux 0.6.5.10.

Начинать знакомство с ZFS стоит с изучения особенностей CopyOnWrite (CoW) файловых систем — при изменении блока данных старый блок не изменяется, а создается новый. Переводя на русский — происходит копирование при записи. Данный подход накладывает отпечаток на производительности, зато даёт возможность хранить всю историю изменения данных.

CoW подход в ZFS даёт огромные возможности: эта ФС не может иметь некорректного состояния, т.к. в случае проблем с последней транзакцией (например при отключении питания) будет использована последняя корректная.

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

Кратко о главных преимуществах ZFS для вашей системы.

контрольные суммы — гарантия корректности данных;
возможность резервирования как на уровне создания зеркал и аналогов RAID массивов, так и на уровне отдельного диска (параметр copies );
в отличие от многих файловых систем с их fsck на уровне журнала, ZFS проверяет все данные по контрольным суммам и умеет проводить их автоматическое восстановление по команде scrub (если в пуле есть живая копия битых данных);
первая ФС, разработчики которой честно признались во всех возможных рисках при хранении — везде при упоминании ZFS можно встретить требование оперативной памяти с поддержкой ECC (любая ФС имеет риск повреждения при отсутствии ECC памяти, просто все, кроме ZFS, предпочитают не задумываться об этом);
ZFS создавалась с учетом ненадёжности дисков, просто помните это и перестаньте волноваться о вашем ~~WD GreenSeagateetc~~ (только, если рядом трудится ещё один выживший диск).

Максимальная гибкость вашего хранилища:

закончилось место? Замените диск на более объёмный, и ваш покорный ZFS сам займёт новоотведённое ему место (по параметру autoexpand);
лучшая реализация снапшотов среди файловых систем для Linux. На это подсаживаешься. Инкрементально по сети, в архив, ~~/dev/null~~, да хоть раздвойте личность вашего дорогого Linux в реальном времени (clone);
нужно больше ~~золота~~ места? 256 зебибайт хватит всем!

Структура.

В ZFS структура хранилища выглядит следующим образом:

В пуле может быть неограниченное количество vdev, что позволяет создать пул из двух и более mirror, RAID-Z или других сочетаний. Также доступны классические RAID10 и т.д.

Типы массивов:

Stripe — обычный RAID0.

Mirror — RAID1 на манер ZFS — реплицируются только занятые блоки, забудьте о синхронизации пустого места.

RAID-Z — создавался как замена RAID5-6, но имеет большие отличия:

— каждый блок данных — аналог отдельного массива (с динамической длинной);
— отсутствует проблема write hole;
— при ребилде создаются только данные (т.е. риск сбоя в этот момент уменьшается). Также в тестовой ветке уже находятся улучшения, которые дополнительно ускорят этот процесс.

Рекомендуется использовать RAID-Z2 (аналог RAID6). При создании RAID-Z стоит обязательно изучить эту статью, основные нюансы:

— IOPS равен самому медленному диску (создавайте RAID-Z с наименьшим количеством дисков);
— эффективность утилизации места увеличивается при бОльшем количестве дисков в массиве (требуется задать корректный recordsize, см. ссылку выше);
— в существующий массив RAID-Z нельзя добавить ещё один диск (пока), но можно заменить диски на более ёмкие. Эта проблема решается созданием нескольких массивов в рамках одного vdev.

dRAID (в разработке) — базируется на наработках RAID-Z, но при сбое позволяет задействовать на чтение-запись все диски массива.

ARC — умное кеширование в ZFS.

CoW ухудшает производительность. Для сглаживания ситуации был создан adaptive replacement cache (ARC). Его основная особенность в проработанных эвристиках для исключения вымывания кеша, в то время как обычный page cache в Linux к этому очень чувствителен.

Бонусом к ARC существует возможность создать быстрый носитель со следующим уровнем кеша — L2ARC. При необходимости он подключается на быстрые SSD и позволяет заметно улучшить IOPS HDD дисков. L2ARC является аналогом bcache со своими особенностями.

L2ARC стоит использовать только после увеличения ОЗУ на максимально возможный объём.

Также существует возможность вынести запись журнала — ZIL, что позволит значительно ускорить операции записи.

Дополнительные возможности.

Компрессия — с появлением LZ4 позволяет увеличить скорость IO за счёт небольшой нагрузки на процессор. Нагрузка настолько мала, что включение данной опции уже является повсеместной рекомендацией. Также есть возможность воспользоваться другими алгоритмами (для бекапов прекрасно подходит gzip).

Дедупликация — особенности: процесс дедупликации производится синхронно при записи, не требует дополнительной нагрузки, основное требование —

320 байт ОЗУ на каждый блок данных (Используйте команду zdb -S название_пула для симуляции на существующем пуле) или

5гб на каждый 1 тб. В ОЗУ хранится т.н. Dedup table (DDT), при недостатке ОЗУ каждая операция записи будет упираться в IO носителя (DDT будет читаться каждый раз с него).
Рекомендуется использовать только на часто повторяющихся данных. В большинстве случаев накладные расходы не оправданы, лучше включить LZ4 компрессию.

Снапшоты — в силу архитектуры ZFS абсолютно не влияют на производительность, в рамках данной статьи на них останавливаться не будем. Отмечу только прекрасную утилиту zfs-auto-snapshot, которая создаёт их автоматически в заданные интервалы времени. На производительности не отражается.

Шифрование (в разработке) — будет встроенным, разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/receive и scrub отправлять и проверять данные на целостность без ключа.

Основные рекомендации (TL;DR):

— Заранее продумайте геометрию массива, в настоящий момент ZFS не умеет уменьшаться, а также расширять существующие массивы (можно добавлять новые или менять диски на более объёмные);

— используйте сжатие:
compression=lz4

— храните расширенные атрибуты правильно, по умолчанию хранятся в виде скрытых файлов (только для Linux):
xattr=sa

— отключайте atime:
atime=off

— выставляйте нужный размер блока (recordsize), файлы меньше recordsize будут записываться в уменьшенный блок, файлы больше recordsize будут записывать конец файла в блок с размером recordsize (при recordsize=1M файл размером 1.5мб будет записан как 2 блока по 1мб, в то время как файл 0.5мб будет записан в блок размером 0.5мб). Больше — лучше для компрессии:
recordsize=128K

— ограничьте максимальный размер ARC (для исключения проблем с количеством ОЗУ):
echo «options zfs zfs_arc_max=половина_ОЗУ_в_байтах» >> /etc/modprobe.d/zfs.conf
echo половина_ОЗУ_в_байтах >> /sys/module/zfs/parameters/zfs_arc_max

— дедупликацию используйте только по явной необходимости;

— по возможности используйте ECC память;

— большинство SSD врёт системе о размере блока, для перестраховки контролируйте его (параметр ashift). Ссылка на список исключений для SSD в коде ZFS.

Важные моменты:

— многие свойства действуют только на новые данные, к примеру при включении сжатия оно не применится к уже существующим данным. В дальнейшем возможно создание программы, применяющей свойства автоматически. Обходится простым копированием.
— консольные команды ZFS не запрашивают подтверждение, при выполнении destroy будьте бдительны!
— ZFS не любит заполнение пула на 100%, как и все другие CoW ФС, после 80% возможно замедление работы без должной настройки.
— требуется правильно выставлять размер блока, иначе производительность приложений может быть неоптимальна (примеры — Mysql, PostrgeSQL, torrents).
— делайте бекапы на любой ФС!

В настоящий момент ZFS on Linux уже является стабильным продуктом, но плотная интеграция в существующие дистрибутивы будет проходить ещё некоторое время.

ZFS — прекрасная система, от которой очень сложно отказаться после знакомства. Она не является универсальным средством, но в нише программных RAID массивов уже заняла своё место.

Я, gmelikov, состою в проекте ZFS on Linux и готов с радостью ответить на любые вопросы!
Отдельно хочу пригласить к участию, всегда рады issues и PR, а также готовы помочь вам в наших mailing lists.

Update (12.02.2018): Добавлена информация про ashift SSD дисков.

Источник