The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."  +/
Сообщение от auto_tips (??) on 03-Сен-10, 23:50 
Рекомендации по тюнингу некоторых системных параметров в 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...
Обсуждается: http://www.opennet.dev/tips/info/2425.shtml

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от V (??) on 03-Сен-10, 23:50 
неплохо
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от temny email(??) on 04-Сен-10, 07:02 
Ключи монтирования ext3 (IMHO) написаны весьма небрежно:
- noatime "включает в себя" nodiratime, соответственно nodiratime можно не указывать;
- async это дефолтная опция монтирования ext3, т.е. также можно не указывать, плюс утверждение "опция async не подходит для СУБД" в контексте ext3 звучит как миниму "странно";
- commit=1 - весьма спорно, какой смысл форсировать коммит транзакций журнала каждую секунду? скорее переход на более редкую (по сравнению с дефолтной) периодичность коммитов (т.е использование значений выше commit=5) может позволить сгрупировать (взаимоисключить?) какие-то транзакции, уменьшив количество дисковых операций (но увеличив время отката журнала в случае fsck);
- data=journal - приведёт к тому, что в журнал будут записываться не только метаданные, но и данные(!) - т.е. добровольно "почти удваиваем" количество записываемых на диск данных (так же это косвенно повышает требования к размеру журнала). Подобный режим работы будет оправдан в исключительных/редких случаях, я бы не стал использовать этот режим как "правило"
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."  +/
Сообщение от pavlinux (ok) on 04-Сен-10, 12:54 
>Если 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 группы - не ясно.


----------

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."  +1 +/
Сообщение от аноним on 04-Сен-10, 16:02 
>> В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%
>То есть в 10 раз!!! Ага.... Сказочники.

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."  +/
Сообщение от pavlinux (ok) on 04-Сен-10, 16:57 
>>> В итоге удалось снизить нагрузку на CPU для XFS с 30% до 0.3%
>>То есть в 10 раз!!! Ага.... Сказочники.
>
>в 100, батенька, в 100

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."  +/
Сообщение от Аноним (??) on 05-Сен-10, 23:30 
А что такого? При оптимальной конфигурации файловой системы - в разы меньше перемещений голов туда-сюда и соответственно iowait может запросто уменьшиться в разы. Например: закопируй на винч 5Гб файл локально одним махом. И качни его же торентом, без преаллокации. А потом сделай чтение нахолодную (чистый кеш дисков без этих файлов, например сразу после перезагрузки ОС) обоих файлов и сравни iowait, тебе понравится. Там и в 100 раз может быть разница :-)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Раздел полезных советов: Тюнинг LVM, RAID, XFS и EXT3 при ин..."  +/
Сообщение от pavlinux (ok) on 06-Сен-10, 00:00 
>А что такого? При оптимальной конфигурации файловой системы - в разы меньше
>перемещений голов туда-сюда и соответственно iowait может запросто уменьшиться в разы.
>Например: закопируй на винч 5Гб файл локально одним махом. И качни
>его же торентом, без преаллокации. А потом сделай чтение нахолодную (чистый
>кеш дисков без этих файлов, например сразу после перезагрузки ОС) обоих
>файлов и сравни iowait, тебе понравится. Там и в 100 раз
>может быть разница :-)

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от i (??) on 06-Сен-10, 09:30 
на sgi.com писали про число Allocation Group нужно выбирать исходя из принципа:
1-AG на 4Gb данных, но это наверно как раз для Hi-end серверов/массивов
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от sluge (ok) on 07-Сен-10, 15:09 
а что про ext4 забыли
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от Аноним (??) on 08-Сен-10, 09:05 
какими попугаями меряли, какая методика???
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от sandro email on 11-Сен-10, 11:30 
>> В итоге удалось снизить нагрузку на 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 и некое хранилище вообще. Что в оригинале подчёркивется.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Тюнинг LVM, RAID, XFS и EXT3 при интенсивной обработке мелки..."  +/
Сообщение от pavlinux (ok) on 01-Окт-10, 03:01 
Кстати, osyncisdsync больше не будет.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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