The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Тюнинг 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 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 и позволяет увеличить производительность при многопоточной записи, но
постепенно приводит к накоплению паразитной фрагментации в ФС.
 
02.09.2010 , Источник: http://www.techforce.com.br/news/li...
Ключи: speed, optimization, ext3, xfs, disk, tune / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Диски и файлы / Файловые системы

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, V, 23:50, 03/09/2010 [ответить] [смотреть все]
  • +/
    неплохо
     
  • 1.2, temny, 07:02, 04/09/2010 [ответить] [смотреть все]
  • +/
    Ключи монтирования ext3 IMHO написаны весьма небрежно - noatime включает в с... весь текст скрыт [показать]
     
  • 1.3, pavlinux, 12:54, 04/09/2010 [ответить] [смотреть все]  
  • +/
    Вот скажите мне уважаемые оптимизаторы, То есть в 10 раз Ага Сказочники ... весь текст скрыт [показать]
     
     
  • 2.4, аноним, 16:02, 04/09/2010 [^] [ответить] [смотреть все]  
  • +1 +/
    >> В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%
    >То есть в 10 раз!!! Ага.... Сказочники.

    в 100, батенька, в 100

     
     
  • 3.5, pavlinux, 16:57, 04/09/2010 [^] [ответить] [смотреть все]  
  • +/
    >>> В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%
    >>То есть в 10 раз!!! Ага.... Сказочники.
    >
    >в 100, батенька, в 100

    Ну да... ещё веселее

     
     
  • 4.6, Аноним, 23:30, 05/09/2010 [^] [ответить] [смотреть все]  
  • +/
    А что такого При оптимальной конфигурации файловой системы - в разы меньше пере... весь текст скрыт [показать]
     
     
  • 5.7, pavlinux, 00:00, 06/09/2010 [^] [ответить] [смотреть все]  
  • +/
    >А что такого? При оптимальной конфигурации файловой системы - в разы меньше
    >перемещений голов туда-сюда и соответственно iowait может запросто уменьшиться в разы.
    >Например: закопируй на винч 5Гб файл локально одним махом. И качни
    >его же торентом, без преаллокации. А потом сделай чтение нахолодную (чистый
    >кеш дисков без этих файлов, например сразу после перезагрузки ОС) обоих
    >файлов и сравни iowait, тебе понравится. Там и в 100 раз
    >может быть разница :-)

    Достали уже с вашими безумными фантазиями.
    Проделайте эти все эти тесты, желательно 9 раз каждый, RAW результаты сюда.
    Тогда про анализируем и обсудим. А то,- "может, например, потом, после,...",
    теоретики ...ля.

     
  • 1.8, i, 09:30, 06/09/2010 [ответить] [смотреть все]  
  • +/
    на sgi.com писали про число Allocation Group нужно выбирать исходя из принципа:
    1-AG на 4Gb данных, но это наверно как раз для Hi-end серверов/массивов
     
  • 1.9, sluge, 15:09, 07/09/2010 [ответить] [смотреть все]  
  • +/
    а что про ext4 забыли
     
  • 1.10, Аноним, 09:05, 08/09/2010 [ответить] [смотреть все]  
  • +/
    какими попугаями меряли, какая методика???
     
  • 1.11, sandro, 11:30, 11/09/2010 [ответить] [смотреть все]  
  • +/
    >> В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%
    >То есть в 10 раз!!! Ага.... Сказочники.

    Это кривые руки переводчика, не умеющего технические стать переводить. У них не нагрузка на CPU уменьшилась, а время ожидания процессором завершения ввода/вывода. Нагрузка на CPU реально растёт. Причём примерно пропорционально увеличению производительности по моему личному опыту(использовал Bonnie++). Ну и т.д. 2^27 байт - в оригинале минимальный размер AG для ядра 2.6.26, и вообще, речь там идёт о конкретно Debian Lenny + IBM DS 8300 с 8 дисками в RAID 5 + ИХ SMTP сервер + ИХ нагрузка на сервер, а не Linux и некое хранилище вообще. Что в оригинале подчёркивется.

     
  • 1.12, pavlinux, 03:01, 01/10/2010 [ответить] [смотреть все]  
  • +/
    Кстати, osyncisdsync больше не будет.
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor