Применимость: Linux, физический сервер или XEN/KVM-VDS
Слова для поиска: тюнинг, tuning
Как получить максимальную производительность от файловой системы?
До того как вы начали ставить систему на ваш сервер продумайте конфигурацию и параметры RAID массива.
Каждый физический том 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
Ускорение ext4 за счёт увеличения вероятности проблем, ключи монтирования:
noatime,nodiratime,noacl,data=writeback,commit=15
Пример команды для установки режима журналирования по умолчанию:
tune2fs -o journal_data_writeback /dev/vg_name/vol
Существует три разных варианта журналирования файловой системы ext3:
Планировщик ввода вывода (по умолчанию используется CFQ) может существенно влиять на производительность. Выбор оптимального варианта зависит от режима использования.
echo "noop" > /sys/block/<device>/queue/scheduler
Имеет смысл для лучшей производительности файловой системы указывать при создании количество дисков в рейде и количество блоков файловой системы которое может поместиться в один страйп ( 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
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 включите опцию issue_discards в файле /etc/lvm/lvm.conf По умолчанию используется issue_discards = 0, для включения установите issue_discards = 1.
В Linux доступно предварительное чтение данных с диска, но это создает дополнительную нагрузку. Слишком агрессивный параметр read ahead может попросту перегрузить дисковую подсистему
Посмотреть текущий:
blockdev --getra /dev/sda
Поменять:
blockdev --setra <новое значение в килобайтах> /dev/md?
Актуальность: 2013/12/12 09:11