Настройки 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 может улучшить производительность всех типов приложений сереверов.

1
# zfs set atime=off dataset

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

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

1
# zfs set compression=[on|off] dataset

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

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

1
># zfs set dedup=on

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

1
# zdb –D pool

Или

1
# zdb –DD pool

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

1
# zdb –S pool

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

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

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

1
# zfs send tank/a@s1 | mbuffer –m 128M | zfs receive tank2/a@s1

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

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

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

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

1
2
3
Vfs.zfs.arc_min: Минимальный размер ARC (в байтах)
Vfs.zfs.arc_max: Максимальный размер ARC (в байтах)
Vfs.zfs.arc_meta_limit: Лимит метаданных 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(в байтах), запустите:

1
# sysctl.kstat.zfs.misc.arcstats.size

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

1
2
# sysctl vfs.zfs.arc_meta_used
# sysctl vfs.zfs.arc_meta_limit

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

1
# zfs set primarycache=[all|metadata|none] dataset

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

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

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

1
2
# zfs add pool cache device
# zfs remove pool device

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

1
2
3
4
5
6
vfs.zfs.l2arc_feed_again: turbo warmup
vfs.zfs.l2arc_feed_secs: interval secs
vfs.zfs.l2arc_write_max: max write size
vfs.zfs.l2arc_write_boost: extra write during warmup
vfs.zfs.l2arc_headroom: number of dev writes to precache
vfs.zfs.l2arc_noprefetch: don’t cache prefetch bufs

первый параметр выше включает или выключает 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, например для потокового видео или веб серфинга больших файлов.

1
# sysctl vfs.zfs.l2arc_noprefetch=1

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

1
# zfs set secondarycache=[all|metadata|none] dataset

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

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

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

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

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

1
2
# zpool add tank log device
# zpool remove tank device

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

1
# zfs set sync=[standard|always|disabled] dataset

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

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

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

1
vfs.zfs.prefetch_disable: Disable prefetch

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ARC Size: 79.89% 25.57 GiB
Target Size: (Adaptive) 79.89% 25.57 GiB
Min Size (Hard Limit): 12.50% 4.00 GiB
Max Size (High Water): 8:1 32.00 GiB
ARC Efficiency: 1.25b
Cache Hit Ratio: 90.52% 1.13b
Cache Miss Ratio: 9.48% 118.08m
Actual Hit Ratio: 84.54% 1.05b
Data Demand Efficiency: 95.45% 356.90m
Data Prefetch Efficiency: 40.64% 11.36m
L2 ARC Breakdown: 118.18m
Hit Ratio: 62.87% 74.29m
Miss Ratio: 37.13% 43.89m
Feeds: 849.64k
File-Level Prefetch: (HEALTHY)
DMU Efficiency: 28.09b
Hit Ratio: 88.54% 24.87b
Miss Ratio: 11.46% 3.22b

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

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

1
# sysctl -d vfs.zfs.vdev.cache

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

1
vfs.zfs.vdev.cache.size=10485760

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 секунд)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ZFS real-time cache activity monitor
Seconds elapsed: 120
Cache hits and misses:
1s 10s 60s tot
ARC hits: 259 431 418 466
ARC misses: 51 40 49 52
ARC demand data hits: 223 417 390 437
ARC demand data misses: 36 20 17 16
ARC demand metadata hits: 36 11 25 25
ARC demand metadata misses: 15 19 21 25
ARC prefetch data hits: 0 4 3 4
ARC prefetch data misses: 0 1 10 8
ARC prefetch metadata hits: 0 0 0 0
ARC prefetch metadata misses: 0 0 1 3
L2ARC hits: 47 34 40 37
L2ARC misses: 4 5 9 15
ZFETCH hits: 47903 47294 48155 47138
ZFETCH misses: 272 449 1147 3593
Cache efficiency percentage:
10s 60s tot
ARC: 91.51 89.51 89.96
ARC demand data: 95.42 95.82 96.47
ARC prefetch data: 80.00 23.08 33.33
ARC prefetch metadata: 0.00 0.00 0.00
L2ARC: 87.18 81.63 71.15
ZFETCH: 99.06 97.67 92.92

• Учет снижения предела меданных 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 килобайт перед популярным набором данных:

1
# zfs create -o recordsize=8k tank/mysql

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

NFS серверы

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

1
# zfs set sync=disabled dataset

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

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

1
ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)

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

1
# zdb –C [poolname]

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

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

1
2
3
4
5
6
# gnop create –S 4096 ada0
# zpool create tank ada0.nop
# zpool export tank
# gnop destroy ada0.nop
# zpool import tank
# zdb –C tank | grep ashift

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

Заключение

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

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

Оставить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *