купить одеяло киев недорого, onlin.

Авторизация

Вы можете войти через одну из учетных записей:

ИЛИ



Напомнить пароль
Регистрация

РуководствоТюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелких файлов

Рекомендации по тюнингу некоторых системных параметров в Debian/GNU Linux для оптимизации работы высоконагруженных систем, производящих тысячи одновременных запросов к массиву из десятка миллионов мелких файлов (например, типичная
ситуация для нагруженного почтового сервера с maildir). В итоге удалось снизить время ожидания процессором завершения ввода/вывода (I/O wait) для XFS с 30% до 0.3%, а для EXT3 до 5%.

Для увеличения производительности при большом числе параллельных дисковых операций рекомендуется использовать хранилища, подключенные через 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 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 и позволяет увеличить производительность при многопоточной записи, но
постепенно приводит к накоплению паразитной фрагментации в ФС.
  • +1
  • android
  • 14 сентября 2010, 16:23
  • add twitter 

Комментарии (0) Вконтакте (0) facebook (0)

Комментарии (0)

rss свернуть / развернуть

Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.