Mylex 170, RAID1 и Windows 2000

[Tomahawk]

Я долго раздумывал для какого именно форума моя проблема. Размышления привели меня сюда.

Имеем железо:
сервер на материнке от SuperMicro, 2*Xeon 2.4Ghz, 2G RAM
raid-контроллер Mylex AcceleRAID 170
6 дисков IBM IC35L036UCD210-0 на одном шлейфе в корзине с хотсвапом (корпус Inwin R3000).

Конфигурация массивов простая как дважды-два: 3 зеркала по 2 диска в каждом: #0+#3, #1+#4, #2+#5.

ОС: Windows 2000 Server + SP3. Со стороны операционки дисков видать тоже 3. Логических дисков на них тоже сделано три - C, D и E.
Одинакового размера (~36Г), на каждом NTFS. Обновление modification time в системе отключено.

Проблема же состоит в том, что "со всем этим мы попробуем взлететь"... не взлетает. Нет, оно работает вполне исправно! Но скорость...

Изначально я не стал включать write cache на массиве. Но увидев по некоторым тестам скорость записи на диск C: в районе 4Mb/sec - я не то чтобы расстроился... я офигенно расстроился!

Включение write cache не шибко-то и помогло... скорость поднялась примерно втрое, примерно до 12Mb/sec.

Померив производительность работы с дисками D: и E:, я ещё больше оторопел - 26-30Mb/sec на запись со включенным write cache меня более чем устраивает.

Суть вопроса в следующем. Кто-нибудь может объяснить такую разницу в работе логических дисков под W2K? Что я мог упустить?
Может ли быть виноватым железо?

p.s.
IOmeter пускать нет никаких сил - оно пытается создать файл ТАКОГО размера , что моего терпения не хватает на то, чтобы дождаться завершения фазы 'preparing...'

p.p.s.
это только первый сервер. а у меня ведь ещё и второй есть. точно то же железо, но массив по другому сконфигурён. и там тоже есть проблемы...

[a_shats]

Уважаемый:
1. Зачем 3 зеркала ? Учтите, что производительность на запись на зеркале невысока по определению. А настроив RAID1 системный том и RAID 0+1 на данные получите производительность на запись (на томе с данными) в разы повыше, при той же емкости массива.
2. Что-то Вы сильно странно настроили... Каков объем кэша на контроллере и чем (и как) Вы измеряете производительность ?
По поводу IOMeter можете посмотреть в FAQ на данном форуме (методики измерения).
Что касается непосредственно Вашего вопроса: скорее всего, Вы установили доменный контроллер. Суть: ОС не видит "железных" кэшей и имеет собственный файловый кэш - как на чтение, так и на запись. Ну так вот, для системного тома кэш на запись отключается при установке AD - и включить потом его можно, лишь удалив AD как класс .Делается это для пущей надежности.
Кроме того: а зачем, собственно, на системном томе высокая производительность на запись ? Пишутся туда-то только логи ведь-редко и немножко . Временные файлы (ну и свап в крайнем случае) можно легко перебросить на более быстрый массив.
Насчет modification time - Вы имели в виду NTFS last access update ?
Ну и ладно.

[gs]

По поводу иометра - необязательно ждать окончания создания тестового файла. Достаточно залить гигабайт и обрубить иометр. Потом если его снова запустить, он подумает, что все уже создано.

Попробуйте все же иометром посмотреть - мы знаем его поведение, а с другими тестами - неясно, что они мерят.

[gs]

Еще я бы проверил настройки скази шины на всех дисках - может быть на каком-то винте просто 10МГц стоит.

Я не имею в виду, что есть проблема - может это фича виндов, тем более что остальные логические драйвы показывают вполне нормальную скорость. Но если есть сомнения, проверить не мешает.

Кстати, действительно странно, зачем три отдельных зеркала? Может быть сделать один драйв груп и на нем несколько 0+1? При неравномерной нагрузке на разные массивы это даст прирост общей скорости (перераспределение).

[Tomahawk]

Ввиду недостатка времени флеймить не буду. Отвечу пока на два момента:

1. зачем три зеркала:

Изначально я хотел делать RAID5 "на все деньги", оставивив один винт в Hot Spare. Однако, обсуждение данного вопроса с некоторыми сисадминами привело к некоторым непоняткам. В частности, утверждается, что IBMовские диски этой серии были замечены за тем, что вешали насмерть всю систему путём блокирования шины в момент вылета одного из дисков. Но это лирика, которая не относится к проблеме.

Специфика этой машинки в том, что она является сервером Sybase ASE, и на втором и третьем зеркале я держу данные и логи баз соответственно. Надежда на распараллеливание процесса, так сказать. Помогает это или нет - пока не знаю.

Ну и "железный" момент. Вылет двух дисков в RAID5 вроде бы получается более вероятен, чем вылет двух дисков, составляющих одно зеркало из трёх. Всё это и привело к такой организации массива.

2. про IOMeter.
Мысль с обрубанием его в процессе создания тестового файла мне понравилась. Буду экспериментировать. Если сработает - будет замечательно.

[Tomahawk]

Всё-таки запустил IOMeter по предложенной методике.

Итоговые результаты в окошке "results display":
total I/Os per second = 268.70
total MBs per second = 0.52
average I/O response time (ms) = 37.2151
maximum I/O response time (ms) = 291.0561
%CPU Utilization = 4.91%
error count = 0

на мой взгляд, результаты удручающие.

[Tomahawk]

2. Что-то Вы сильно странно настроили... Каков объем кэша на контроллере и чем (и как) Вы измеряете производительность ?

размер кэша на контроллере - 32M

Что касается непосредственно Вашего вопроса: скорее всего, Вы установили доменный контроллер. Суть: ОС не видит "железных" кэшей и имеет собственный файловый кэш - как на чтение, так и на запись. Ну так вот, для системного тома кэш на запись отключается при установке AD - и включить потом его можно, лишь удалив AD как класс .Делается это для пущей надежности.

Увы, доменный контроллер торчит на "родном братце" этой машины. Эта лишь состоит в этом домене в качестве обычного сервера. Но информация по части кэширования записи на системном томе мне в новинку. Не знал, не знал...

Кроме того: а зачем, собственно, на системном томе высокая производительность на запись ? Пишутся туда-то только логи ведь-редко и немножко

С одной стороны - конечно пофигу это всё. Но мой опыт общения с серверами, построенными на IDEшных дисках и простейшем Promise FastTrak TX2 в режиме RAID1 показывает, что что-то с моими современными дорогими "наворотами" не так. Причём сильно не так.

[Tomahawk]

Еще я бы проверил настройки скази шины на всех дисках - может быть на каком-то винте просто 10МГц стоит.

Я посмотрел те данные, которые выводит GAM-клиент. Судя по ним - все диски сидят в 160Mb/sec. Или мегагерцы где-то в другом месте смотрятся?

[gs]

Иометр - штука достаточно сложная. Тот тест, что Вы, видимо, запустили имитирует работу базы данных с одним потоком запросов. Т.е. случайное чтение и запись коротких блоков (2кБ).
Если Вас интересует другой вид нагрузки, зайдите в Access Specifications и настройте как захочется. Например, чтобы померить линейную скорость, надо выставить 100% Sequental и Transfer Request Size побольше (например 64кБ). Percent Read\Write означает соотношение запросов чтения и записи. Количество одновременных потоков данных задается # of Outstanding I/Os.

В общем, попробуйте разобраться - не пожалеете.

[a_shats]

Tomahawk
Хм. Да я вообще-то не флейма ради, а детального ответа для
1. Канал-то у Вас один, при серьезных проблемах с одним винтом он может по-любому завалить все, что на этом канале сидит, так что - зеркало не поможет, а производительность в сравнении с 0+1 лихо просадит.
2. Где разница в вероятности отказа винтов для разных типов массивов ? Ее нет. Отказ-то - не логический, однако. Я имею в виду, что вероятность "железного" отказа никак не зависит от типа массива, в котором винт установлен - а только от самого винта.
3. По поводу системного тома - тогда действительно нужно внимательно пройтись по настройкам SCSI для всех винтов.
Я отчего спрашивал про кэш: при тестировании дискового массива "прокачиванием" потока файлов/блоков, заведомо по размерам вылезающих за кэш, начинаются суровые тормоза. Сам видел неоднократно . А кэш на Вашем контроллере - минимальный.
О специфике БД: имхо, аппаратное распараллеливание записи на контроллере должно быть несколько эффективнее, нежели программное распараллеливание средствами БД. Применяется оно наиболее эффективно(программное распараллеливание) обычно при отсутствии аппаратного RAID - как вынужденная мера.

[Tomahawk]

Хм. Да я вообще-то не флейма ради, а детального ответа для

а мне вот как-то правды хочется. а то возникает дебильное ощущение, что деньги как-то не за то заплачены. понты есть, а толку нет.

1. Канал-то у Вас один, при серьезных проблемах с одним винтом он может по-любому завалить все, что на этом канале сидит, так что - зеркало не поможет, а производительность в сравнении с 0+1 лихо просадит.

Согласен. При таких проблемах разницы в завале системы никакой

2. Где разница в вероятности отказа винтов для разных типов массивов ? Ее нет. Отказ-то - не логический, однако. Я имею в виду, что вероятность "железного" отказа никак не зависит от типа массива, в котором винт установлен - а только от самого винта.

Я рассуждал с точки зрения тривиального отказа, когда система остаётся полностью работоспособной. В этом случае выход из строя сразу двух дисков всё-таки порушит систему и приведёт к останову ОС. А вот вылет двух дисков, стояищих в разных логических зеркалах ничего плохого не сделает - система останется работоспособной.

3. По поводу системного тома - тогда действительно нужно внимательно пройтись по настройкам SCSI для всех винтов.

Всё доступное я вроде облазил - ничего подозрительного не нашёл.

Я отчего спрашивал про кэш: при тестировании дискового массива "прокачиванием" потока файлов/блоков, заведомо по размерам вылезающих за кэш, начинаются суровые тормоза. Сам видел неоднократно . А кэш на Вашем контроллере - минимальный.

Соглашусь. Просто я в какой-то мере смотрю на свои субьективные ощущения относительно того сервера, который был у меня на предыдущей работе. При том, что он был весь на дешёвом IDE и вообще без кэша, работало всё в комплексе субьективно быстрее.

О специфике БД: имхо, аппаратное распараллеливание записи на контроллере должно быть несколько эффективнее, нежели программное распараллеливание средствами БД.

Так я и не использую распараллеливание средствами БД. Просто положил файлы на разные физические устройства, чтобы всё было побыстрей.

[a_shats]

В обратном порядке пройдусь :
Суть Вашего распараллеливания: есть "демон" записи собственно БД, и "демон" пишущий лог. Так ? И Вы разложили БД и лог (ну, может еще что-нибудь окромя лога) на разные тома. ОК. Теперь эти демоны могут писать как бы одновременно. Ну и что ? Винты-то располагаются физически на одном канале одного контроллера. И быстрее, чем он может, запись производиться все равно не будет . Ну да ладно - как говорится, на вкус и цвет...
А вообще - этот Ваш контроллер может писать до 40 Мбайт/с. Реально может. На чтение с учетом кэша - солидно быстрее.
Посмотреть можно на http://www.mylex.ru/analisys.htm .
Там же можно посмотреть, какой уровень RAID для Вашей задачи эффективнее.
Что касательно данных GAM: U160 SCSI это - частота 80 МГц на 16-бит шине. Поэтому Вас и просили посмотреть именно эти настройки SCSI: частоту и ширину шины. На производительность эти параметры могут оказать просто-таки кардинальное влияние. Даже один винт, посаженный, скажем, на 40 МГц и 8-бит , может просадить до этих значений буквально все устройства на этом канале. Причем в установках может быть все правильно, но винт по какой-либо причине (дефекты, проблемы с электроникой, шлейфом, терминацией, еще одна банальная причина - слабый/некачественный БП (6 винтов не шутка,300 Ватт даже хорошего БП на одновременную раскрутку (spinning up) всех 6 винтов не хватит)) сам съедет в более низкий по скорости режим. Вышеуказанные параметры можно глянуть в GAM и BIOS контроллера.

[Dmitry]

to Tomahawk

Imho циферки производительности Вам не нравятся только потому, что: Вы привыкли к производительности одного процесса при линейном чтении/записи IDE винтов. Свойства SCSI и конкретно RAID проявляются именно на множественной нагрузке.
Проверьте четко такую же конфигурацию IOMETER на IDE системе и увидете, что все скорости значительно ниже и % загрузки CPU значительно выше. А если нагрузку еще увеличите на IDE (в тех пределах когда на RAID все прекрасно работает), то по экрану монитора не сможете сдвинуть мышку.
Вот и разница в производительности.

[gs]

Действительно, сравнивать можно только две разные машины на ОДНОЙ И ТОЙ ЖЕ задаче и с одинаковой нагрузкой.
А ИДЕ диски на одном потоке данных мало отличаются от сказевых. Зато при увеличении нагрузки разница проявляется в разы.

А вот сообщение о том, что на системном диске скорость сильно отличается от других, заслуживает рассмотрения. Я пока не представляю, какая разница, но посмотреть стоит. Если у Вас конечно не аппаратная проблема и операционка нормально стоит. Кстати, GAM у Вас установлен? Не сообщает ли он об ошибках? Что говорит consistency check?