The OpenNET Project / Index page

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

Тюнинг 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 "включает в себя" nodiratime, соответственно nodiratime можно не указывать;
    - async это дефолтная опция монтирования ext3, т.е. также можно не указывать, плюс утверждение "опция async не подходит для СУБД" в контексте ext3 звучит как миниму "странно";
    - commit=1 - весьма спорно, какой смысл форсировать коммит транзакций журнала каждую секунду? скорее переход на более редкую (по сравнению с дефолтной) периодичность коммитов (т.е использование значений выше commit=5) может позволить сгрупировать (взаимоисключить?) какие-то транзакции, уменьшив количество дисковых операций (но увеличив время отката журнала в случае fsck);
    - data=journal - приведёт к тому, что в журнал будут записываться не только метаданные, но и данные(!) - т.е. добровольно "почти удваиваем" количество записываемых на диск данных (так же это косвенно повышает требования к размеру журнала). Подобный режим работы будет оправдан в исключительных/редких случаях, я бы не стал использовать этот режим как "правило"
     
  • 1.3, pavlinux (ok), 12:54, 04/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Если XFS необходимо оптимизировать для работы ....
    >++ Оптимизация на этапе монтирования:
    >
    >XFS:
    >   noatime,nodiratime,attr2,nobarrier,logbufs=8,logbsize=256k,osyncisdsync

    Вот скажите мне уважаемые оптимизаторы,
    > В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%

    То есть в 10 раз!!! Ага.... Сказочники.

    какую роль в оптимизации играет attr2 - ускоряющую или замедляющую? :)
    Не, attr2 прикольная фича, тока после надо правильно расширенные атрибуты выставлять.

    > то число Allocation Group нужно выбирать исходя из принципа ...

    Универсальный рецепт - 32 группы.

    > C учетом того, что Linux-ядро поддерживает
    > минимальный размер Allocation Group в 2^27 байт

    Э-ээ-э-э-э, типа man mkfs.xfs(2)


        agsize=value

    This is an alternative to using the agcount suboption. The value is the desired size of the allocation group expressed in bytes (usually using the m or g suffixes). This value must be a multiple of the filesystem block size, and must be at least 16MiB, and no more than 1TiB, and may be automatically adjusted to properly align with the stripe geometry. The agcount and agsize suboptions are mutually exclusive.

    В общем, 1 группа должна быть кратна размеру блока, быть не менее 16Мб, но не более 1Тб.

    > Если XFS необходимо оптимизировать для работы с большими файлами, то число
    > Allocation Group нужно выбирать исходя из принципа - одна группа на одно ядро CPU.

    Как автор будет делать на 16 Тб хранилище при 4-ядерном проце, 4 группы - не ясно.


    ----------

    Статья очередной маразматическо-аналитический копипаст изо всех мест.

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

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

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

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

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

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




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру