Colobridge WIKI

оптимизация файловой системы ext3-ext4

Применимость: Linux, физический сервер или XEN/KVM-VDS

Слова для поиска: тюнинг, tuning


Как получить максимальную производительность от файловой системы?

До того как вы начали ставить систему на ваш сервер продумайте конфигурацию и параметры RAID массива.

  • Если вас заботит производительность, обязательно используйте контроллер с BBU.
  • Если для вас недоступно использование функций SSD кэширования Adaptec MaxIQ, LSI CacheCade и т.п., то можно рекомендовать использовать RAID10 c максимальным количеством дисков для получения максимальных значений IOPS.
  • Если же у вас есть какой либо SSD Cache способный кэшировать запись и чтение, то оптимальным решением может быть RAID6 + SSD Cache. RAID10 в сочетании с SSD Cache не дает преимуществ в скорости и проигрывает в пространстве.
  • Может оказаться, что набор из большого количества SAS дисков будет обеспечивать бОльшую скорость последовательного чтения/записи чем ваши SSD диски в CacheCade. При этом вы таки получите ускорение по IOPS, но потеряете в линейных характеристиках.
  • При создании массива используйте медленную инициализацию. При этом контроллер сможет оптимально упорядочить расположение данных по дискам.

Каждый физический том LVM делится на части, которые называются физическими экстентами (Physical Extents, PE). Размер физических экстентов может варьироваться, но един в пределах группы томов. В пределах физического тома каждый физический экстент имеет уникальный номер. Физический экстент – минимальный блок пространства, который может быть адресован системой LVM на физическом хранилище.

Когда вы будете устанавливать систему, при создании LVM групп по умолчанию будет использован extent размером 4МБ. Это не повлияет на производительность если у вас небольшое пространство. Однако если речь идет о десятках террабайт, то следует учитывать, что ядро должно будет держать в памяти все метаданные связанные с экстентами и тратить на их обработку вычислительную мощность.

Размер экстента задается при создании группы томов. Изменить размер экстента нельзя.

Из этих соображений желательно выбрать размер экстента как можно больше. Существенным ограничением здесь может быть размер желаемого минимального шага при определении размера LVM томов. Например если вам в одном случае нужен том 1100МБ, в другом 1400МБ, то ваш размер экстента - 100МБ. Если же вы планируете отмерять тома только в гигабайтах, то смело выбирайте размер экстента 1024МБ.

Версия файловой системы EXT4 более производительна чем EXT3, относительно недавно она признана стабильной, но это мнение разработчиков.

Вероятность возникновение проблем с ext4 несколько выше, чем при использовании ext3. Это и теоретически и практически.

Дата признания стабильности ext3 - ноябрь 2001 года. Для ext4 - 21 октября 2008 года.

Иногда говорят проблемах с ext4 в виде потери данных при отключении питания. Наиболее частая причина этому - небрежность разработчиков некоторых приложений игнорирующих необходимость выполнения fsync при сохранении данных. Эта проблема еще может быть связана с отложенным выделении блоков и интервалом сброса на диск метаданных (параметр монтирования commit=nrsec). В Ext4 после закрытия файла до фактической записи данных на диск может проходить до 150 секунд. Если в этот момент….

Короче - ext3 надежнее, ext4 быстрее.

Создание файловой системы

Для маленьких файлов:

mkfs -t ext4 -m 0 -O dir_index,filetype /dev/vg_name/vol
tune2fs -o journal_data_writeback /dev/vg_name/vol

Для больших файлов:

mkfs -t ext4 -m 0 -T largefile4 -O extents,filetype,has_journal,sparse_super /dev/vg_name/vol
tune2fs -o journal_data_writeback /dev/vg_name/vol

Монтирование

Важные для производительности опции mount для ext4

  • data={ordered|journal|writeback} (данные пишутся до метаданных, данные журналируются, порядок записи не отслеживается)
  • commit=секунд (5; интервал между sync; для увеличения производительности увеличить)
  • barrier|nobarrier (использовать барьеры для упорядочивания запросов записи; для дисков без кеша записи или с батарейкой можно отключить, что увеличит производительность)
  • inode_readahead=32
  • orlov (новый алгоритм выделения блоков)
  • oldalloc (старый алгоритм выделения блоков)
  • user_xattr|nouser_xattr
  • acl|noacl
  • reservation|noreservation (?)
  • bsddf|minixdf
  • errors={continue|remount-ro|panic}
  • quota|noquota (считать квоту по пользователям)
  • grpquota|usrquota (считать квоту по группам)
  • bh|nobh (привязывать «buffer heads» к страницам данных для гарантии упорядочивания; отключать можно только для «data=writeback»)
  • delalloc|nodelalloc (отложенное до момента записи выделение блоков)
  • max_batch_time=микросекунд (15000; максимальное время ожидания следующего запроса при склейке запросов синхронной записи)
  • min_batch_time=микросекунд (0; увеличение улучшает пропускную способность многопотоковой синхронной записи за счёт увеличения задержек)
  • journal_ioprio=приоритет (3; от 0 - высший - до 7; обычный ввод-вывод имеет приоритет 4)
  • auto_da_alloc|noauto_da_alloc (борьба с обнулением файлов после аварийного отключения)

Ускорение ext4 за счёт увеличения вероятности проблем, ключи монтирования:

  • barriers=0 (по умолчанию, используются барьеры синхронизации в очереди запросов)
  • data=writeback[,nobh] (можно получить мусор в открытых на момент сбоя файлах)
  • stripe= (подобрать в соответствии с используемым RAID)
  • commit=10 (по умолчанию делается sync каждые 5 секунд)
  • journal_async_commit[,journal=update] (не ждать завершения записи журнала)
  • max_batch_time=30000,min_batch_time=10000 (по умолчанию, параметры пакования запросов - 15000 и 0)
Рекомендуемые параметры
noatime,nodiratime,noacl,data=writeback,commit=15
barrier=0

Writeback по умолчанию:

Пример команды для установки режима журналирования по умолчанию:

tune2fs -o journal_data_writeback /dev/vg_name/vol

Существует три разных варианта журналирования файловой системы ext3:

  • Journal Mode (самый медленный, наиболее безопасный)
  • Ordered Mode (средняя скорость, очень безопасный, опция по умолчанию)
  • Writeback Mode (наиболее быстрый, относительно безопасный)

IO scheduler

Планировщик ввода вывода (по умолчанию используется CFQ) может существенно влиять на производительность. Выбор оптимального варианта зависит от режима использования.

echo "noop" > /sys/block/<device>/queue/scheduler

Оптимизация под RAID (Chunk size)

Имеет смысл для лучшей производительности файловой системы указывать при создании количество дисков в рейде и количество блоков файловой системы которое может поместиться в один страйп ( chunk ), это особенно важно при создании массивов уровня RAID0,RAID5,RAID6,RAID10.

Для RAID1 ( mirror ) это не имеет значения так как запись идет всегда на один device, a в других типах рейдов дата записывается последовательно на разные диски порциями соответствующими размеру stripe.

Например если мы используем RAID5 из 3 дисков, с дефолтным размером страйпа в 64К и используем файловую систему ext3 с размером блока в 4К то можно вызывать команду mkfs.ext вот так:

 
mkfs.ext3 -b 4096 -E stride=16 stripe-width=32 /dev/md0

Для расчетов используйте калькулятор параметров для файловых систем на RAID

Оптимизация для SSD

TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных уже не содержатся в файловой системе и могут быть использованы накопителем для физического удаления.

Проверка поддержки TRIM

hdparm -I /dev/sda |grep TRIM

пример проверки

hdparm -I /dev/sdb |grep TRIM
           *    Data Set Management TRIM supported (limit 1 block)
           *    Deterministic read data after TRIM

Для использования этой функции примените опцию монтирования discard

Или установите для использования по умолчанию:

tune2fs -o discard /dev/sdXY

Или при создании файловой системы добавьте опцию:

mkfs.ext4 -E discard /dev/sdXY
TRIM на уровне LVM

Для использования TRIM на уровне LVM включите опцию issue_discards в файле /etc/lvm/lvm.conf По умолчанию используется issue_discards = 0, для включения установите issue_discards = 1.

В Linux доступно предварительное чтение данных с диска, но это создает дополнительную нагрузку. Слишком агрессивный параметр read ahead может попросту перегрузить дисковую подсистему

Посмотреть текущий:

blockdev --getra /dev/sda

Поменять:

 blockdev --setra <новое значение в килобайтах> /dev/md?