Рекомендации по тюнингу некоторых системных параметров в Debian/GNU Linux для оптимизации работы высоконагруженных систем, производящих тысячи одновременных запросов к массиву из десятка миллионов мелких файлов (например, типичная ситуация для нагруженного почтового сервера с maildir). В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%, а для EXT3 до 5%, затрачиваемых на операции ожидания ввода/вывода (I/O wait).Для увеличения производительности при большом числе параллельных дисковых операций рекомендуется использовать хранилища, подключенные через Fiber Channel, и использовать технологию Multipath для организации доступа к хранилищу, подключенному через несколько каналов (путей) ввода/вывода.
Повысить производительность можно подключив несколько дисков в LVM и RAID, используя "striping"-режим без контроля целостности. Оптимальная производительность для программного RAID при обработке небольших файлов достигается при размере stripe-блока 4 Мб и размере chunk-а 256 Кб. Важное значение имеет также выравнивание файловых систем, LVM и RAID относительно внутренней группировки дисков в хранилище (учитываем физические параметры массива для логически предоставляемого хранилищем раздела).
Например, имея хранилище IBM DS 8300 из 8 дисков, подключенных по Fiber Channel и объединенных в RAID5, будет использовать разбиение на 8 каналов ввода/вывода:
# pvcreate /dev/mapper/mpath0
# pvcreate /dev/mapper/mpath1
...
# pvcreate /dev/mapper/mpath7
# vgcreate --autobackup y grupo1 /dev/mapper/mpath0 /dev/mapper/mpath1 \
/dev/mapper/mpath2 /dev/mapper/mpath3 /dev/mapper/mpath4 /dev/mapper/mpath5 \
/dev/mapper/mpath6 /dev/mapper/mpath7
# lvcreate --autobackup y --readahead auto --stripes 8 --stripesize 4096 \
--size 1,95T --name lvstripe2 grupo1
++ Оптимизация файловых систем:
Ext3 плохо подходит для конфигурация с большим объемом параллельных запросов, но показывает лучшую производительность при однопоточной обработке мелких файлов, на производительность Ext3 также отрицательно влияет накапливающаяся со временем фрагментация данных. Оптимальным решением при высокой параллельной нагрузке и при работе с очень большими файлами является XFS, в случае использования нескольких Allocation Group.
При использовании XFS, операции по выравниванию относительно stripe-раздела LVM или RAID производятся автоматически. Для Ext3 обязательно нужно рассчитывать смещение вручную, иначе будет наблюдаться падение производительности (http://busybox.net/~aldot/mkfs_stride.html http://wiki.centos.org/HowTos/Disk_Optimization)
++ Форматирование ФС.
Существенная разница в плане оптимизации состоит в том, что в ext3 используется только одна таблица inode, что приводит к необходимости использования очереди запросов. В XFS отдельная таблица inode создается для каждой Allocation Group, при этом каждая из групп может функционировать и изменяться параллельно, не влияя на другие группы.
Ext3: При запуске mke2fs следует использовать опцию "-T", выбрав в качестве аргумента оптимальный план форматирования, приведенный в файле /etc/mke2fs.conf, например "mke2fs -T small".
XFS: минимизируем число Allocation Group к размеру квоты на пользователей почтового сервера, так как при создании директорий XFS пытается создать новую директорию в еще не заполненной Allocation Group. C учетом того, что Linux-ядро поддерживает минимальный размер Allocation Group в 2^27 байт, то рассчитать число групп (agcount) можно по формуле: желаемый размер хранилища / (2^27)
Например (4096 - размер блока, 128m - размер лога мета-данных):
-l internal,lazy-count=1,size=128m -d agcount=399 -b size=4096
или
-l internal,lazy-count=1,size=128m -d agsize=268435456 -b size=4096
Для поднятия производительность лог мета-данных можно перенести в отдельный пул, размещенный на SSD-накопителе.
Если XFS необходимо оптимизировать для работы с большими файлами, то число Allocation Group нужно выбирать исходя из принципа - одна группа на одно ядро CPU.
++ Оптимизация на этапе монтирования:
XFS:
noatime,nodiratime,attr2,nobarrier,logbufs=8,logbsize=256k,osyncisdsync
при этом, nobarrier указываем только для хранилищ класса High-End, а osyncisdsync не нужно указывать при работе СУБД.
Ext3:
noatime,nodiratime,async,commit=1,data=journal,reservation
при этом, опция async не подходит для СУБД, commit=1 и data=journal можно указать для высоконагруженных серверов. Опция reservation (предварительное выделение inode для содержимого создаваемых директорий) работает начиная с ядра 2.6.13 и позволяет увеличить производительность при многопоточной записи, но постепенно приводит к накоплению паразитной фрагментации в ФС.
URL: http://www.techforce.com.br/news/linux_blog/lvm_raid_xfs_ext...
Обсуждается: https://www.opennet.ru/tips/info/2425.shtml
Вариант для распечатки
(??) on 04-Сен-10, 07:02 
