Настройки ZFS на FreeBSD

ZFS это современная 128-битная файловая система основанная на модели копирование-на-запись. Она произошла из проекта OpenSolaris и впервые появилась в FreeBSD в 2008. ZFS имеет много инновационных характеристик включая интегрированный менеджер томов с зеркалированием и возможностями RAID, контрольные суммы данных и сжатие, записываемые снэпшоты, которые могут быть перемещены между системами и многое другое.

Что вы будете знать…
• Как оптимизировать ZFS для различных приложений и рабочих нагрузок
• Как измерить и оценить эффективность кэша ZFS

Что вы должны знать…
• Базовые навыки администрирования ZFS системы
• Работать с параметрами настройки sysctl(8) и loader(8)

В этой статье я буду обсуждать несколько параметров тюнинга включая sysctl(2) и дам примеры как производительность и эффективность ZFS может быть измерена и оценена. Эта статья предназначена для пользователей FreeBSD с ZFS версии 28 доступной с 8.3-RELEASE и 9.0-RELEASE.
ZFS имеет много параметров тюнинга доступных с помощью команды sysctl(8). В дополнение к этому, ZFS является частью OpenSolaris фреймворка kstat(kernel statistics facility), который также доступен в FreeBSD предоставляя сырые статистические данные от различных счетчиков. Существует более 60 параметров настроек vfs.zfs и более 80 параметров настроек kstat.zfs предоставляющих доступ к разным счетчикам ядра, состояниям и калибровочным переменным. В настоящее время есть весьма ограниченное количество инструментов для обработки этой информации.
Первый раздел этой статьи сосредоточится на тюнинге zfs предвыборки и кэша, вводя zfs-stats и zfs-mon инструменты обработки статистики для измерения и оценки. За ними следуют отдельные советы, по использованию ZFS на веб, база данных или файловых серверах, и оптимизация под жесткие диски расширенного формата (4k сектор).

Основные советы по тюнингу

Оперативная память

Количество оперативной памяти системы имеет значительное воздействие на производительность ZFS, особенно если использовать дедубликацию. Много вопросов может быть исправлено увеличением оперативной памяти системы. Рекомендуемая память минимум 1Гб, но я предлагаю для активно используемых настроек по крайней мере, 8 Гб. Для серверов использующих коррекцию ошибок ECC памяти это будет преимуществом.

Время доступа

На FreeBSD, каждый раз, когда происходит обращение к файлу время доступа (atime) обновляется. Это может сформировать большое количество записей на диск на сервере работающем с большим числом файлов. В таком случае вы захотите отключить atime (время доступа) для пострадавших данных или для всего пула. Отключение atime может улучшить производительность всех типов приложений сереверов.

Сжатие данных

Использование сжатия данных в ZFS сохраняет пространство но имеет негативный эффект на производительность CPU системы и отзывчивости. С другой стороны, включение сжатия (главным образом LZJB) может повысить производительность ваших данных, особенно на медленных носителях. В частности стоимость сжатия gzip существенно больше процессорного времени, чем меньший уровень сжатия LZJB сжатие. Поэтому я рекомендую использовать сжатие данных только если вы имеете сжимающиеся данные и наборы данных это не бутылочное горлышко производительности или если у вас мало дискового пространства. Наборы данных с низкой активностью содержат, например, журнальные файлы хорошие кандидаты для gzip сжатия. Если вы имеете быстрый накопитель с достаточным пространством и нужна первоклассаная производительность, отключите сжатие набора данных для поврежденных наборов данных.

Дедупликация

ZFS дедупликация относительно новая характеристика, которая включается вами для сохранения пространства хранением единственной копии данных, которые доступны на ваших ZFS наборах данных в множественных копиях. Дедупликация необходима при огромном количестве оперативной памяти. Идеальная ситуация если ваша вся таблица дедупликации вписывается в памяти, в противном случае вы можете получить опыт снижения производительности системы. Дедупликация может быть включена и/или отключена на основе набора данных:

Вы можете увидеть (подробно) информацию о дедупликации пула используя команду zdb:

Или

Это возможно имитировать эффект от включения дедупликации для пула. Чтобы проверить возможные выгоды пространства, в результате дедупликации отношение более чем на 2 указывает на хорошего кандидата для дедупликации.

Обсуждая преимущества и стоимость ZFS дедупликации доступно в блоге Константина Гонзалеса (http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-notdedupe)

ZFS отправка/получение

Если вы используете отправку и получение и запускаете их в одно и тоже время (если вы не заливаете поток в файл, но трубопровод ZFS отправка напрямую в zfs получение) тогда вы должны учитывать использование буферизованные решения для повышения скорости обработки. Я лично рекомендую mbuffer программудоступную в FreeBSD портах как misc/mbuffer. Mbuffer позволяет вам буферизовать локальные потоки (через трубу) и способный автономно посылать поток по сети.

Тюнинг кэша и предвыборки

Адаптивная замена кэша

Один из главных настраиваемых характеристика ZFS это основанная на памяти Адаптивная Замена Кэша (ARC). Данные и метаданные читаются блоками с дискового устройства на котором хранятся в его кэше. ARC предоставляет основное повышение скорости в операциях ZFS и включается по умолчанию.

Основной loader(8) настраивается для ARC:

С этими настройками вы можете контролировать размер лимитов кэша ARC на вашей системе. Минимальный и максимальный значения для ARC автоматически измеряются во время загрузки системы, в зависимости от установленной оперативной памяти. Значения по умолчанию:

vfs.zfs.arc _ max: Физическая память меньше 1 Гб(or vm.kmem _
size, все, что меньше)
• vfs.zfs.arc _ meta _ limit: ¼ от arc _ max
• vfs.zfs.arc _ min: половина arc _ meta _ limit (равняется
1/8 arc _ max)

И arc_min и arc_max имеют жесткий минимум 16MB и оба arc_meta_limit и arc_min не могут быть выше чем arc_max. Для отображения текущего размера ARC(в байтах), запустите:

По умолчанию значения должны быть достаточными для большинства пользователей, как если вашей системе необходима память для других задач, ARC память автоматически освобождается, сокращается до значения arc_min. Измените vfs.zfs.arc_max только для улучшения если вам нужно точно зарезервировать память для другого использования. Альтернативно там могут быть ситуации когда ваши метаданные кэша заполняются (например вы имеете большое количество маленьких файлов) и вы заметите плохую производительность вашего ARC. В такой ситуации вы можете захотеть повысить arc_meta_limit(улучшется loader(8)). Пожалуйста заметьте, что arc_min жестко должен быть по крайней мере половину arc_meta_limit.
Отобразить ваш текущий ARC исползования метаданных и предел метаданных (в байтах), запустите:

По умолчанию, ARC включен на всех наборах данных. Если у вас был опыт проблем с производительностью по причине полного и неэффективного ARC вы можете решить отключить ARC или предел кэша только метаданных на некритичных наборах данных:

Для отображения аптайма и реального времени активности ARC и эффективности, пожалуйста обратитесь к разделу этой статьи zfs-stats и zfs-mon.

Второй уровень адаптивной замены кэша (L2ARC)

Быстрое блочное устройство (например, SSD диски) могут быть использованы в расширенном ARC кэше определенных пулов ZFS. Этот кэш называется Второй уровень адаптивной замены кэша (L2ARC). Этот тип кэша в основном оптимален на одну запись и множественные чтения сценариев хранилища, например, статический контент веб сайтов в Интернете с изображениями и видео файлами, которые не перезаписываются (но общее пространство используется для увеличивающегося хранения). Для этого необходимо устройства с быстрым кэшем (использование быстрых SSD дисков рекомендуемо). Напротив, чтобы ARC был общим для всей системы, L2ARC устройств пул с привязкой и кэшем только данных из пула к которому они прикреплены.
Размер L2ARC кэша определяен размером кэша устройств. Добавить/удалить кэш устройств из пула, вы можете использовать следующие команды:

L2ARC предоставляет несколько системных параметров настройки, я приведу следующий пример:

первый параметр выше включает или выключает L2ARC турбо режим warm-up. Турбо режим warm-up фаза происходящая между загрузкой системы и получением кэшем L2ARC состояния “warm” (= первое выселение данных L2ARC). В течение этой фазы ARC записывает вычисленное как l2arc_write_max + l2arc_write_boost в байтах каждые l2arc_feed_secs секунд. Если фаза warm-up выключена или L2ARC уже в состоянии warm, данные записаны на максимальной скорости l2arc_write_max байт каждые l2arc_feed_secs секунд. Настройки по умолчанию при включенном warm-up l2arc_feed_secs установлен в одну секунду и оба l2arc_write_max и l2arc_write_boost установлен в 8Мб. L2arc_headroom параметры определяются количеством L2ARC записей, которые были предкешированы. Значение по умолчанию 2.
Цель этих настроек уберечь от перезаписи SSD устройства слишком быстро, так как они имеют ограниченное число циклов перезаписи. Эти настройки определялись в 2008 и современные SSD диски могут легко работать на больших скоростях. Существуют рекомендации в по крайней мере двух vfs.zfs.l2arc_write_max и vfs.zfs.l2arc_write_boost loader(8) настроить в 16Мб.
L2arc_noprefetch определяют настройку в 0 по умолчанию. Это отключает кэширование последовательного чтения. Включение этих настроек (значение 1) в большинстве случаев улучшает производительность L2ARC, например для потокового видео или веб серфинга больших файлов.

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

Для отображения uptime и реального времени активности L2ARC и эффективности, пожалуйста обратитесь к разделам статьи zfs-stats и zfs-mon.

ZFS глубокий журнал (ZIL)

ZIL предоставляет синхронизационный смысл для ZFS. Он используется, чтобы гарантировать целостность данных при вызове fsync(2). Он использует повторные транзакции данных в случаях когда сбой происходит в ядре, аппаратном обеспечении или отключении питания.

По умолчанию ZIL занимает маленькое количество дискового пространства в каждом пуле ZFS. Он может быть использован для ускорения синхронизации записи, разделения устройства журнала (включая зеркалированные устройства). Для этих целей рекомендуется использовать быстрые SSD диски.

Чтобы добавить или удалить устройство журнала в пул, используйте следующие команды:

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

При установке синхронизации с отключением, данные записываются на хранение только периодически (TXG – Транзакция Группы). Это улучшает производительность записи, но вносит риск потери данных при сбоях в ядре, аппаратном сбое или отключении питания и делает этот параметр интересным только для временных или быстрои изменяющихся данных. Настройка синхронизации всегда привносит большие издержки в производительности.

Предварительная загрузка уровня файлов (zfetch)

Механизм предварительной загрузки файлов реализован в ZFS и называется zfetch. Это механизм анализирует шаблоны чтения файлов и пытается предсказать результаты следующего чтения для сокращения времени отклика приложений. При некоторых рабочих нагрузках, zfetch может интенсивно нагружать процессор и иметь предел масштабируемости. Эффективная предварительная загрузка может быть показана и отображена утилитами zfs-status, zfs-mon(обсуждается позже). Zfetch включена по умолчанию (отключена на системах с меньшее чем 4 Гб ОЗУ) и вы можете отключить или заново включить установив следующее в загрузчике переключатель в 1 (отключено) и 0 (включено):

Предварительная загрузка уровня устройств (предварительная загрузка vdev)

vdev механизм предварительной загрузки заранее читает данные после маленьких чтений из пула устройств. В настоящий момент, предварительная загрузка vdev кэш отключен по умолчанию. Длительное применение показало, что это неэффективно в большинстве случаев и ее применение памяти пропорционально количеству vdev в системе.

Листинг 1. Пример вывода zfs-stats

Существует пользовательские отчеты, в которых при заново включенном vdev кэше значительно ускоряется чистка (и ресилвер) обработка устройств на raid-z (или системы с медленными дисками) за счет сокращения времени поиска на диске и ускорения чтения метаданных.

Предварительная загрзука vdev в основном управляется vfs.zfs.vdev.cache.size loader(8) переключатель, который содержит размер кэша vdev устройства в байтах и отключен по умолчанию (в значении 0). Для опытных пользователей, существуют несколько дополнительных параметров настройки для тонкой настройки доступны vfs.zfs.vdev.cache loader(8) перестраиваемая группа.

Для включения предварительной загрузки vdev установите vfs.zfs.vdev.cache в loader.conf(5) в желаемый размер в байтах отличный от нуля, предварительное значение по умолчанию имеет значение в 10 Мб.

zfs-stats и zfs-mon: инструменты статистики ZFS

kstat.zfs sysctl(8) параметр предоставляет доступ к множеству переменных счетчиков ZFS. Эти переменные содержат исходные данные и делают некоторые выводы из этих переменных, промежуточные значения должны быть вычислены. Perl скрипты zfs-stats и zfs-mon обрабатывают эти данные и предоставляют вывод в удобном для человека виде. Zfs-stats утилита основана на arc_summary.pl Бена Роквуда и включает изменения сделанные Джейсоном Хелленталем и мной. Оба эти инструмента доступны в портах FreeBSD в sysutils/zfs-stats. Данные из zfs-stats суммируются и/или средние значения счетчиков, которые собирают данные из системы после того как она загрзилась. Пример отрывка вывода из zfs-stats: Листинг 1.

Средний uptime не говорит много о действительной производительности системы. Для отображения кэша эффективности (или исходного количества) в реальном времени я написал утилиту zfs-mon. Она отслеживает ARC, L2ARC и zfetch в реальном времени и выводит 10 секундные, 60 секундные и общее средние значения в секунду (общее = с тех пор как программа была запущена).
Пример zfs-mon –a вывод после сбора 120 секундных данных: Листинг 2.

Как общий кэш эффективности L2ARC кэш доступен только на системе без ARC, так ваш общий кэш эффективности вычисляется используя следующую формулу:

[ARC efficiency] + (100-[ARC efficiency])*([L2ARC efficiency]/100).

Результат для примера выше:

89,96 + (100-89,96)*(71,15/100) = 97,10.

Интерпретация вывода zfs-stats и zfs-mon

Вывод zfs-stats и zfs-mon может помочь вам открыть места узкого горлышка и решить изменить некоторые недостаточные значения. Главное отображаемое значение это использование и эффективность различных кэшей. Значение эффективности 100% означает, что все чтения с диска выполнены. Для моих целей, эффективность выше 80% считается эффективным, а выше 90% считается высокоэффективным. Помните, что L2ARC занимает некоторое время для разогрева и предназначен для общего улучшения вашего кэша. При использовании zfs-mon, попробуйте собирать данные за длительный период времени и посмтрите колонку tot.

Вот некоторые основные значения:

Неэффективный кэш данных ARC:
• Если вы имеете лимитированный размер ARC, увеличьте или удалите лимит
• Отключите ARC для некоторых наборов данных

Листинг 2. Пример вывода zfs-mon (время запуска 120 секунд)

• Учет снижения предела меданных ARC
• Добавьте больше ОЗУ в вашу систему
• Учитывайте использование дополнительного L2ARC устройство кэша

Неэффективный кэш метаданных ARC:

• Учитывайте повышение предела метаданных ARC
• Добавьте больше ОЗУ в вашу систему

Неэффективный кэш L2ARC:

• Это зависит от очень многого в структуре вашего чтения
• Если ваш ARC уже очень эффективен, L2ARC может на некоторое время добавить только небольшое преимущество
• Если ваш ARC неэффективен, тоже, учтите повышение системной памяти и L2ARC
• В некоторых сценариях эффективеность в 30-40% L2ARC может уже быть доступна

Неэффективность ZFETCH:

• Учтите отключение zfetch

Неэффективность предварительной загрузки vdev:

• Учтите отключение предварительной загрузки vdev
• Если включено, чистка и ресилвер могут работать значительно быстрее
• Измените дополнительные настройки предварительной загрузки vdev (только для экспертов)

Тюнинг ZFS для приложений

Вебсерверы

На FreeBSD, опытный пользователь может увидеть, что это преимущество отключение SendFile и mmap на вашем веб-сервере, если вы обслуживаете ваши страницы с набором данных ZFS. В противном случае ваши данные могут кэшироваться в памяти дважды, а это снижает системную память.

Вот примеры конфигурационных директив для популярных веб-серверов:

Apache

EnableMMAP Off
EnableSendfile Off

Nginx

Sendfile Off

Lighttpd

server.network-backend = “writev”

Серверы баз данных

Для баз данных таких как PostgreSQL и MySQL, пользователям рекомендуется хранить их в наборе данных, созданных различными размерами записи, чем задано по умолчанию 128 килобайт.

Для PostgreSQL и MySQL (MyISAM хранилище), устанавливается размер записи в 8 килобайт перед популярным набором данных:

Для MySQL InnoDB хранилище файлов (не журналируемые) устанавливают размер записи в 16 килобайт, журналы должны быть оставлены с размером записи по умолчанию (вам нужно распространить данные в несколько наборов данных, которые имеют различные размеры записи).

NFS серверы

Если обмен наборами данных ZFS на сервере NFS с большим количеством записей, ZIL может быть вашим бутылочным горлышком. Для улучшений производительности, вы можете захотеть переместить ZIL на отдельное устройство журнала (быстрый SSD диск) или попробовать отключить ZIL для поврежденных данных. Отключение ZIL может привести к повреждению NFS клиента.

ZFS и 4к Сектор Диска

Первоначально жесткие диски используются для хранения данных в 512 байтах физических секторов. Большие жесткие диски сегодня используют Расширенный Формат (4к секторов) и обеспечивают 512 байт сектора в режиме совместимости. В FreeBSD, указанные диски обычно все еще сообщают о размере сектора в 512 байт.

ZFS использует это значение, когда определяет размер блока для устройства, когда добавляет его в пул (или когда пул создан). Просмотрите вашу конфигурацию устройства пула, используя следующую команду:

Параметр “ashift” описывает размер блока ZFS используемый размер как 2^[ashift]. Значение «9» означает 512 байтный сектор. Чтобы иметь 4 килобайтные блоки, необходимо значение «12».

Пользователи сообщают о плохой производтельности с Расширенным Форматом жестких дисков и ashift=9, особенно в конфигурациях RAIDZ. Чтобы создать пул оптимизированный для 4 Кбайт секторам, мы должны сделать размер блока ZFS соответствующим размеру физического сектора, некоторые делают трюк с поддельным устройством gnop. Давайте предположим, что мы хотим создать новый пул на устройстве /dev/ada0.

На настройке с 4к блоком, небольшие файлы до 4к всегда занимают один целый блок. Метаданных ZFS во много раз меньше чем 4кб. Пожалуйста, обратите внимание, что использование ashift=12 увеличивает начальное пространство необходимое для метаданных до довольно большого количества (около 5% от общего размера диска). В зависимости от ваших данных, может увиличиться нагрузка на ваш пул при заполнении данными (например, много мелких файлов). Так что это эффективный компромисс между производительность и свободным дисковым пространством и вам придется решать, что для вас важней.

Заключение

По умолчанию значения настроек ZFS предназначены для пользователей со средним опытом. Эта статья раскрыла несколько путей по оптимизации системы для ZFS и как улучшить эти значения для определенного рабочего окружения. Оценка инструментов zfs-stats и zfs-mon предоставляет необходимое измерение данных.
ZFS это большая часть программного обеспечения и я использую его в основном на десятках систем в FreeBSD, OpenIndiana и даже Linux. Отсутствие средств измерения и оценки вдохновили меня на работу над zfs-stats и zfs-mon.

Мартин Матуска