|
| 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.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 и некое хранилище вообще. Что в оригинале подчёркивется.
| | |
|