оптимизация xfs+lvm+fc

Херней ты маешься.

Ты о чем?

Ты о чем?

RAID нарезан на куски и эти куски в страйпе. Зачем?

Это бэкапный сервер,куда будут по нфс заезжать оракловый бэкап.

Сеть 10G?

RAID железный. на сервер заезжают луны.Данные луны я объединяю в лвм страйп. Так архитектурно сделано.

Да, 10Гб.Сеть не узкое место.

как максимально вижать много операций write из дисков?

Собрать raid10?

raid10

плюсую

Просьба подсказать где еще могут быть узкие места. Более детально и глубоко проанализировать и заоптимизировать.

К сожалению нет возможности собрать level 10

Диски в рейд собраны на аппаратных рейдах с кешем?

собирай raid0, очевидно же

RAID железный. на сервер заезжают луны.Данные луны я объединяю в лвм страйп.

За счет чего ты предполагаешь увеличить скорость?

Ты делаешь сродни: у тебя один диск нарезанный на разделы, объединяя разделы одного диска в страйп скорость не увеличится.

Всё что ты можешь — это настроить EMC и использовать несколько FC путей (hba x N, switch x N, ...) и соотв. политику multipath на клиенте. Сам же клиент должен взять LUN и отдать его LVM'у без всяких выкрутасов (разве что согласовать размер PE)

Ты делаешь сродни: у тебя один диск нарезанный на разделы, объединяя разделы одного диска в страйп скорость не увеличится.

Только вот дисков у него не 1, а аж 70. И LUN'ы, которые он объединяет в страйп, наверняка с разных RAID-групп (не думаешь же ты, что у него одна RAID-5 группа на 70 дисков?). Так что все правильно он делает.

Насчет страйпа все правильно делаешь. Сам юзаю 64K, -i 4.
Только вот странно, что ты все смотришь на хосте, а не на хранилке - даже не написал, какой конфиг R5 и что у тебя с multipath'ом.
Посмотри, нет ли узких мест на ней самой (FA, диски, кэш).

наверняка с разных RAID-групп (не думаешь же ты, что у него одна RAID-5 группа на 70 дисков?)

У тебя догадки, а я ориентируюсь на исходные данные ТС'а

стородж на 70 дисков ,собранные в 5 raid(emc)

Была масса наводящих вопросов, а он так и не сказал один у него рейд или несколько и как нарезаются ЛУНы

Так что шли бы вы со своими догадками!

З.Ы. Пока у ТС'а один РЕЙД5 он может в гамаке и в лыжах, но толку не будет.

Ну, одна рейд-группа на 70 дисков у него быть не может - раз EMC, то максимум 16.
А значит что? Значит, их несколько! Логика, а не догадки =)

1. Да,аппаратный рэйд и кэшом. 2. Я сделал страйп ,т.к. производительность системы вырастет. 3.Я использую 2 пути FC 4. Я думаю нужно еще какие-то буфера подкрутить ,размер блоков для увеличения iops записи. Возможно ли укзим местом быть сам HBA драйвер ,его буфера и очередя? 5.Я пробовал разные параметры nr_requests ,но результат тот же(

6.Какую инфу предоставить по multipath'ом. ? У меня 2 пути юзается.

вот вывод nmon по скорости записи. Это сервер aix ,который делает бэкап и ложит их в паку ,которая приезжает как NFS с линукс-сервера. В свою очередь на линукс-сервер поданы луны с emc. http://s019.radikal.ru/i629/1508/10/cb90f16e77f0.png

да даже если одна rg, всё равно будет толк.

Очередь : queue/nr_requests ставил 512,2048,4096,60000.

а чего не 100500?

Не будь поцем, сделай хотябы примитивный тест чтения/записи при помощи dd, для каждого ЛУНа по-отдельности, потом одновременный dd на все ЛУНы и сравни скорости отдельных ЛУНов и общую для всех.

Будет материал для размышления, а пока это гадание на кофейной гуще.

Привет кукаретикам.

«Диски пишут с большой задержкой»

Большая - это сколько?

Что толку от того, что ты смотришь только со стороны хоста?
Раз большой latency, то, возможно, узкое место на самом сторедже. И надо смотреть на нем: утилизацию дисков, сache write-pending, latency, host IOs/sec, и т.д. На массиве смотреть, а не на хосте.

HBA на хосте вряд ли будет узким местом. Как уже сказали выше, длины очередей ты какие-то дикие выставлял - у порта массива-то какая длина очереди? Может ли он делать 60000 io/sec? =)))

await= 20-60k avgqu-sz=10-20k

Сторожд не узкое место.

А чего ты ещё ожидаешь с такими очередями? А, ну да, у тебя же tcp прокачан.