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

Технологии постороения кластеров (вычислительных и отказоустойчивых), настройка терминал серверов,
SAN , NAS, FibreChannel, Infiniband

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
Аватара пользователя
art
free-lance moderator
Сообщения: 653
Зарегистрирован: 15 май 2003, 11:25
Откуда: SPb

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

Сообщение art » 10 сен 2007, 13:19

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
Advanced member
Сообщения: 306
Зарегистрирован: 13 июл 2003, 10:01
Откуда: Хабаровский край

Сообщение ITER » 11 сен 2007, 09:23

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

Аватара пользователя
art
free-lance moderator
Сообщения: 653
Зарегистрирован: 15 май 2003, 11:25
Откуда: SPb

Сообщение art » 11 сен 2007, 10:43

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

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

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 11 сен 2007, 10:55

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

Аватара пользователя
art
free-lance moderator
Сообщения: 653
Зарегистрирован: 15 май 2003, 11:25
Откуда: SPb

Сообщение art » 11 сен 2007, 11:23

a_shats писал(а):Ну не то, чтобы ограничивает  :D  На Хитачах и IBM та же история.
Скажем так, не способствует -(

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

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

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

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 11 сен 2007, 11:29

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

ITER
Advanced member
Сообщения: 306
Зарегистрирован: 13 июл 2003, 10:01
Откуда: Хабаровский край

Сообщение ITER » 11 сен 2007, 12:30

art писал(а):а у вас есть аналог 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 сильно погоду не делало.
a_shats писал(а): ...уже на 10 потоках линейных чтения или записи картина становится совсем другой...

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

Аватара пользователя
art
free-lance moderator
Сообщения: 653
Зарегистрирован: 15 май 2003, 11:25
Откуда: SPb

Сообщение art » 11 сен 2007, 12:40

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

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

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

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 11 сен 2007, 13:17

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

Ответить

Вернуться в «Кластеры, Аппаратная часть»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 14 гостей