FF-R2021 скорость с одного LD

[art]

FF-R2021 + 2xF16F-R2J2 +Xyratex JBOD
Две FC полки подключены в dual-loop, Xyratex полка - single-loop на отдельном канале Drive+RCC.
Описано тут: http://www.3nity.ru/viewtopic.htm?t=9780

Удивительным образом не могу получить на одной задаче скорость линейного чтения >70мб сек. Скорость реального копирования либо теста iometer на одном worker находятся в пределах 60-70мб сек. При стрельбе из кеша и 4х worker я всегда получаю теоретический трансфер, т.е. от каналов это не зависит.

Поскольку я проверял это на FC и SATA, на количестве дисков от 8х до 16х и на RAID0 - RAID10 - RAID5, это означает только одно:
- софт контроллера не желает отдавать поток одной задаче, даже если он может быть достигнут.

Для реальной работы не это не представляет затруднений, но я хотел бы получить бОльший трансфер при backup больших файлов.

Разделы инициализированы при настройках контроллера "Caching Parameters = Otimization for Random I/O ",  включено "AV Optimization Mode - Fewer Streaming" (последнее - не повлияло).

Вопросы:
Есть идеи, где можно покрутить, кроме как попытаться сделать backup процесс многозадачным?

Есть ли кто, у кого массивы были инициализированы при "Caching Parameters = Otimization for Sequential I/O " ?

[ITER]

На Xyratex F5402E точно такая же картина, действительно создается впечатление что на одном потоке контроллер ограничивает трансфер зачем то.

[art]

а у вас есть аналог Otimization for [Random I/O] / [Sequential I/O] ?

Я полагаю, что  ограничение трансфера вызвано у меня [Otimization for Random I/O]. Сменить этот режим можно только после удаления и создания заново всех LD, чего, конечно же, я делать не буду ради эксперимента.

[a_shats]

Ну не то, чтобы ограничивает  :D  На Хитачах и IBM та же история.
Связано это, полагаю, с оптимизацией фирмвари и алгоритмами кэширования - уже на 10 потоках линейных чтения или записи картина становится совсем другой.

[art]

Ну не то, чтобы ограничивает  :D  На Хитачах и IBM та же история.

Скажем так, не способствует -(

Например всегда резервирует какие-то буферы per worker, без использования которых FC канал забить невозможно,  и не дает одному потоку занимать их все.  Даже если других workers на канале нет.

Полагаю, что серьезные бородачи, которые 15-20 лет  назад писали FW к могучим аппаратам, не одобряли всякую адаптивную логику. Типа нефиг тут лишние циклы добавлять нашему 16MHz  процессору, да и микрокод должен в 64К уместиться.

А теперь уже и страшно в этот код лезть, и некому..

[a_shats]

Ну да Но есть и другие соображения.
С той же AMS500 всего с 2 полок - тестировали 10GB Оракловую БД на 100 сессий - получили 16К IOps  :shock:
То бишь - в умах разработчиков фирмвари внешний массив и один поток ну никак не совместимы Разве что у видюшных - но там уж больно массивы стремненькие, по большей части...

[ITER]

а у вас есть аналог Otimization for [Random I/O] / [Sequential I/O] ?

Я полагаю, что  ограничение трансфера вызвано у меня [Otimization for Random I/O]. Сменить этот режим можно только после удаления и создания заново всех LD, чего, конечно же, я делать не буду ради эксперимента.

Не, в Xyratex свои настройки (политики read-ahead cache и write back cache size), оптимизации random/sequential там нету. И вообще я бы не рассчитывал сильно на эту фишку. У нас есть старенький инфотренд, там тоже есть такая настройка как у вас, когда я с ним игрался года 4 назад переключение sequential/random сильно погоду не делало.

...уже на 10 потоках линейных чтения или записи картина становится совсем другой...

Уже на 4-х потоках другой расклад  

[art]

Уже на 4-х потоках другой расклад  

Именно так.
У меня 4 workers - магическое число при котором можно достичь теор. трансфера в 185-187мб/c. На 2х workers - 95-100Мб, на 3х - 120-130.

Бородачи же из EMC считают такие числа несерьезными и делят все на 10, вместо 4х -)

И это не зависит ни от iops, ни от типа нагрузки (если в диски не упирается, конечно). Из чего я заключаю, что это похоже на hardcoded выделение буферов для I/O.

[gs]

По этому поводу у нас была долгая возня с одним разработчиком видеоохранного софта, причем очень матерого - до сотен терабайт и хреновой тучи камер. Они пробовали разные системы (преимущественно ИБМ. В том числе 4800, которую трудно обвинить в слабосильности) и везде та же байда. В итоге нам пришлось им прочитать лекцию о пользе многопоточной записи