Содержание

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

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

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


Задача:

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

Решение:

RAID-массив

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

LVM

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

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

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

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

EXT3-EXT4

Версия файловой системы 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

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

Рекомендуемые параметры
noatime,nodiratime,noacl,data=writeback,commit=15
barrier=0

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

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

tune2fs -o journal_data_writeback /dev/vg_name/vol

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

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.

Опережающее чтение (Read-Ahead)

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

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

blockdev --getra /dev/sda

Поменять:

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

Смотрите также:


Актуальность: 2013/12/12 09:11