Скорость записи в RAID 5 в 5-10 раз меньше чем чтения
Модераторы: Trinity admin`s, Free-lance moderator`s
Скорость записи в RAID 5 в 5-10 раз меньше чем чтения
Конфигурация массива:
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
Люди добрые, скажите, нормально-ли это, мне кажется что нет?
Где что посмотреть, если что не так, какой программой.
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 раз меньше чем чтения
По чтению -нормально.
По записи - странновато... Я мерил похожие винты в RAID5 на A170 в корзине от SC5200 - запись при наихудших условиях составляла порядка 10-12 Мб/сек. Причем на неэффективность RAID-контроллера списать это, имхо, нельзя.
Есть пара соображений:
1. PCMark - тест для персональных компьютеров, не оснащенных RAID-контроллерами. Не серверный. Лучше использовать специально разработанный для этого дела Intel IOMeter. Методики - можно поискать здесь и на iхbt.
Т.е. отчасти "виноватым" может оказаться кэш контроллера: PCMark наверняка использует в тестах последовательные запись и чтение на больших объемах. А RAID сильны совсем в других ситуациях - когда чтение и запись идут "вразброс", на разные винты и разные участки. В данной ситуации могло получиться следующее: куча кэш-миссов (последовательные чтение/запись), отсюда - постоянный сброс/загрузка кэша.
2. Ну, как всегда: ставили ли последние дрова, прошивки, каковы настройки и т.п.
По записи - странновато... Я мерил похожие винты в RAID5 на A170 в корзине от SC5200 - запись при наихудших условиях составляла порядка 10-12 Мб/сек. Причем на неэффективность RAID-контроллера списать это, имхо, нельзя.
Есть пара соображений:
1. PCMark - тест для персональных компьютеров, не оснащенных RAID-контроллерами. Не серверный. Лучше использовать специально разработанный для этого дела Intel IOMeter. Методики - можно поискать здесь и на iхbt.
Т.е. отчасти "виноватым" может оказаться кэш контроллера: PCMark наверняка использует в тестах последовательные запись и чтение на больших объемах. А RAID сильны совсем в других ситуациях - когда чтение и запись идут "вразброс", на разные винты и разные участки. В данной ситуации могло получиться следующее: куча кэш-миссов (последовательные чтение/запись), отсюда - постоянный сброс/загрузка кэша.
2. Ну, как всегда: ставили ли последние дрова, прошивки, каковы настройки и т.п.
Я и раньше слыхал про тест IOMeter, но что-то не получается его нигде найти. Intel на своем ftp сервере его куда-то переложила, а все ссылки ведут туда, так-что ищу пока. Если кому не страшно бросте в мыло свежую ссылку.
Наша конкретная задача на сервере MS SQL server чистый объем базы 4GB. В принципе все работает, но при достаточно большом количестве пользователей имеет место заметная потеря быстродействия. Сотрудники говорят что раньше лучше было, хотя тут трудно судить т.к. объемы данных были не те, да и я сам не видел как оно лучше было.
Понимаете-ли в чем дело, на сервере рядом стоит еще IDE-шный винт, дак вот при простом копировании файлов IDE-шный и RAID5 по чтению работают примерно одинаково, а по записи RAID5 проигрывает IDE-шному в 2 раза(!).
Наша конкретная задача на сервере MS SQL server чистый объем базы 4GB. В принципе все работает, но при достаточно большом количестве пользователей имеет место заметная потеря быстродействия. Сотрудники говорят что раньше лучше было, хотя тут трудно судить т.к. объемы данных были не те, да и я сам не видел как оно лучше было.
Понимаете-ли в чем дело, на сервере рядом стоит еще IDE-шный винт, дак вот при простом копировании файлов IDE-шный и RAID5 по чтению работают примерно одинаково, а по записи RAID5 проигрывает IDE-шному в 2 раза(!).
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Операции линейной записи для рэйд контроллеров всегда были слабой стороной. Но что-то действительно медленно. Скорее всего что-то с кэшем. Иногда лучше включить, иногда выключить. Заранее не угадаешь.
Но на базе данных этот параметр рояля не играет. Главное - число и скорость позиционирования головок винтов и эффективность кэша. Если у Вас мегарэйд, то у него кэш хорошо работает, если включен конечно.
Может быть кэша прибавить, может быть винты пошустрее или побольше числом поставить.
А с иометром поиграйте - штука мощная, но с ним надо плотно разобраться - нельзя просто запустить и прочитать показания. Ловите по мылу.
Но на базе данных этот параметр рояля не играет. Главное - число и скорость позиционирования головок винтов и эффективность кэша. Если у Вас мегарэйд, то у него кэш хорошо работает, если включен конечно.
Может быть кэша прибавить, может быть винты пошустрее или побольше числом поставить.
А с иометром поиграйте - штука мощная, но с ним надо плотно разобраться - нельзя просто запустить и прочитать показания. Ловите по мылу.
-
- Advanced member
- Сообщения: 138
- Зарегистрирован: 19 окт 2002, 15:49
- Откуда: г. Волжский, Волгоградская область
- Контактная информация:
У вас на сайте старая версия есть поновее. Кстати мне вот интересно - читая обзоры винтов постоянно вижу графики, построенные на основе тестов IOMeter-ом.. Чем такие графики строить?! Второй момент - где задается глубина очереди команд, что такое outstanding I/O (при увеличении этого параметра, насколько я помню, резко возрастает количество I/O per second)?
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
outstanding IO - грубо говоря, число параллельных запросов. число операций увеличивается по понятным причинам - у скази дисков есть оптимизация очереди команд, да и кэшконтроллера в этом деле помогает.
а версии ПРИНЦИПИАЛЬНЫХ отличий не имеют, насколько я помню года с 99-го.
графики можно строить из экселевского отчета, который он генерит.
З.Ы. читайте мануалы
а версии ПРИНЦИПИАЛЬНЫХ отличий не имеют, насколько я помню года с 99-го.
графики можно строить из экселевского отчета, который он генерит.
З.Ы. читайте мануалы
Ну, что же, протестил 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 винта (я их не привел, но он работает также, даже лучше).
Я думаю, что решение может быть в увеличении количества винтов в массиве.
Поправьте меня, если я не прав.
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
- Откуда: Москва
- Контактная информация:
Вот эти результаты вполне похожи на те, что ожидались.
Но напрягаться так не стоило - тесты (с большим количеством винтов, кстати) уже есть - тут. На любой вкус.
Попробуйте отключить режим Write-Back (отложенная запись) кэша контроллера или-вообще отключить сам кэш - и результаты сильно изменятся...
Уф... Кэш на контроллере (да и любой кэш вообще) максимально эффективен лишь тогда, когда размер данных, с которыми идет работа (чтение/запись/неважно) близок к его размеру(объему).Имхо.
Но напрягаться так не стоило - тесты (с большим количеством винтов, кстати) уже есть - тут. На любой вкус.
Попробуйте отключить режим Write-Back (отложенная запись) кэша контроллера или-вообще отключить сам кэш - и результаты сильно изменятся...
Уф... Кэш на контроллере (да и любой кэш вообще) максимально эффективен лишь тогда, когда размер данных, с которыми идет работа (чтение/запись/неважно) близок к его размеру(объему).Имхо.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя