Скорость записи в RAID 5 в 5-10 раз меньше чем чтения

Поломалось, посыпалось, не работает...

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

Ответить
glob
Junior member
Сообщения: 3
Зарегистрирован: 21 янв 2003, 00:27

Скорость записи в RAID 5 в 5-10 раз меньше чем чтения

Сообщение glob » 21 янв 2003, 00:55

Конфигурация массива:
3 x IBM DDYS-T18350M - RAID 5 на контроллере Mega RAID Express 500
корзина: ESG-SHV SCA HSBP M9 v0.13
1 винт такой же в хотсвапе

В корзине стоит, правда, еще один винт: ZJCS ZJCS2-18GB Работает как отдельное устройство, т.о. в корзине 5 винтов.

По тесту PCMark2002 запись 4.6/5.6 MB/s, чтение 24.7/49.0 MB/s
Люди добрые, скажите, нормально-ли это, мне кажется что нет? :(
Где что посмотреть, если что не так, какой программой.

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

Re: Скорость записи в RAID 5 в 5-10 раз меньше чем чтения

Сообщение a_shats » 21 янв 2003, 01:25

По чтению -нормально.
По записи - странновато... Я мерил похожие винты в RAID5 на A170 в корзине от SC5200 - запись при наихудших условиях составляла порядка 10-12 Мб/сек. Причем на неэффективность RAID-контроллера списать это, имхо, нельзя.
Есть пара соображений:
1. PCMark - тест для персональных компьютеров, не оснащенных RAID-контроллерами. Не серверный. Лучше использовать специально разработанный для этого дела Intel IOMeter. Методики - можно поискать здесь и на iхbt.
Т.е. отчасти "виноватым" может оказаться кэш контроллера: PCMark наверняка использует в тестах последовательные запись и чтение на больших объемах. А RAID сильны совсем в других ситуациях - когда чтение и запись идут "вразброс", на разные винты и разные участки. В данной ситуации могло получиться следующее: куча кэш-миссов (последовательные чтение/запись), отсюда - постоянный сброс/загрузка кэша.
2. Ну, как всегда: ставили ли последние дрова, прошивки, каковы настройки и т.п.

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

Сообщение gs » 21 янв 2003, 03:13

Померяйте Иометром. Остальным доверия особого нет.
Если все то же, то поиграйтесь настройками контроллера (вкл-выкл кэша).
А лучше смотрите как Ваша конкретная задача работает, а то тесты иногда интерпретировать сложно.

glob
Junior member
Сообщения: 3
Зарегистрирован: 21 янв 2003, 00:27

Сообщение glob » 21 янв 2003, 05:16

Я и раньше слыхал про тест IOMeter, но что-то не получается его нигде найти. Intel на своем ftp сервере его куда-то переложила, а все ссылки ведут туда, так-что ищу пока. Если кому не страшно бросте в мыло свежую ссылку.
Наша конкретная задача на сервере MS SQL server чистый объем базы 4GB. В принципе все работает, но при достаточно большом количестве пользователей имеет место заметная потеря быстродействия. Сотрудники говорят что раньше лучше было, хотя тут трудно судить т.к. объемы данных были не те, да и я сам не видел как оно лучше было.
Понимаете-ли в чем дело, на сервере рядом стоит еще IDE-шный винт, дак вот при простом копировании файлов IDE-шный и RAID5 по чтению работают примерно одинаково, а по записи RAID5 проигрывает IDE-шному в 2 раза(!).

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

Сообщение gs » 21 янв 2003, 05:39

Операции линейной записи для рэйд контроллеров всегда были слабой стороной. Но что-то действительно медленно. Скорее всего что-то с кэшем. Иногда лучше включить, иногда выключить. Заранее не угадаешь.
Но на базе данных этот параметр рояля не играет. Главное - число и скорость позиционирования головок винтов и эффективность кэша. Если у Вас мегарэйд, то у него кэш хорошо работает, если включен конечно.
Может быть кэша прибавить, может быть винты пошустрее или побольше числом поставить.
А с иометром поиграйте - штука мощная, но с ним надо плотно разобраться - нельзя просто запустить и прочитать показания. Ловите по мылу.

Аватара пользователя
Dmitry
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 861
Зарегистрирован: 22 авг 2002, 16:12
Откуда: St.Petersburg
Контактная информация:

Сообщение Dmitry » 21 янв 2003, 06:44

Я и раньше слыхал про тест IOMeter, но что-то не получается его нигде найти.
Так у нас на сайте и лежит в разделе download:

[RAF]TAHKuCT
Advanced member
Сообщения: 138
Зарегистрирован: 19 окт 2002, 15:49
Откуда: г. Волжский, Волгоградская область
Контактная информация:

Сообщение [RAF]TAHKuCT » 21 янв 2003, 07:26

У вас на сайте старая версия :) есть поновее. Кстати мне вот интересно - читая обзоры винтов постоянно вижу графики, построенные на основе тестов IOMeter-ом.. Чем такие графики строить?! Второй момент - где задается глубина очереди команд, что такое outstanding I/O (при увеличении этого параметра, насколько я помню, резко возрастает количество I/O per second)?

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

Сообщение gs » 21 янв 2003, 07:38

outstanding IO - грубо говоря, число параллельных запросов. число операций увеличивается по понятным причинам - у скази дисков есть оптимизация очереди команд, да и кэшконтроллера в этом деле помогает.
а версии ПРИНЦИПИАЛЬНЫХ отличий не имеют, насколько я помню года с 99-го.
графики можно строить из экселевского отчета, который он генерит.

З.Ы. читайте мануалы

glob
Junior member
Сообщения: 3
Зарегистрирован: 21 янв 2003, 00:27

Сообщение glob » 24 янв 2003, 19:56

Ну, что же, протестил IOMeter-ом, вот результаты.
csv-формат:
Access Specification name,IOps,MBps,Average Response Time,Maximum Response Time,% CPU Utilization
File Server,170,1.82,11.7,61,1.5
64K Data Streaming Read,717,44.86,2.7,50,3.3
64K Data Streaming Write,114,7.16,17.4,93,1.3
512 Byte Data Random Read,232,0.11,8.6,74,0.5
512 Byte Data Random Write,128,0.06,15.5,84,0.6

Что скажет благородное сообщество?
По моему мнению у нас следующая ситуация:
Успех в модели длинных последовательных чтений обясняется эффективным использованием кеша контроллера. В модели длинных последовательных записей кеш контроллеру не помогает и отсюда провал.
Если обратить внимание на среднее время доступа (Average Response Time), то как-бы получается что наша система все что выигрывает по быстродействию при параллельной записи на два винта, тут же проигрывает на расчете и записи дополнительной информации (для восстановления) на третий винт.
Т.о. если сделать коррекцию результатов в местах явного использовании кеша наш RAID по быстродействию работает как обычный SCSI винт. Это подтверждается тестами другого, аналогичного SCSI винта (я их не привел, но он работает также, даже лучше).
Я думаю, что решение может быть в увеличении количества винтов в массиве.

Поправьте меня, если я не прав.

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

Сообщение a_shats » 27 янв 2003, 10:30

Вот эти результаты вполне похожи на те, что ожидались.
Но напрягаться так не стоило - тесты (с большим количеством винтов, кстати) уже есть - тут. На любой вкус. ;)
Попробуйте отключить режим Write-Back (отложенная запись) кэша контроллера или-вообще отключить сам кэш - и результаты сильно изменятся...
Уф... Кэш на контроллере (да и любой кэш вообще) максимально эффективен лишь тогда, когда размер данных, с которыми идет работа (чтение/запись/неважно) близок к его размеру(объему).Имхо. ;)

Ответить

Вернуться в «Массивы - Технические вопросы, решение проблем.»