Измерение производительности контроллера

[dagr]

Ситуация такая - с некоторых пор меряю  производительность под линухом  только iometer . Из линуховых кажется только он позволяет делать database patterns как в оракле (100% рандом по 8 килобайт блоки ).
Заметил странную закономерность (замечена на нескольких рейд контроллерах ) - если тестить рандомные операции (и запись и чтение)  на файле размером до 20Gb и выставлять 100 Outstanding requets - то получаешь хорошую производительнсть  близкую к теоретической и монитором видно что очередь драйвера заполняется до 100 . Если файл больше или вобще размером с диск - получаешь производительность одного диска и монитор показывает очередь 1-2 .

тестовые конфигурации  такие
1.   Adaptec SCSI RAID 2200S Ultra320   - Raid5 / 4 HDD 10K SCSI 320
2. AMI Enterprise 1600 / Dell PERC3/QC 4-Channel Ultra160 SCSI (128Mb) Raid5 / 4 HDD 10K SCSI 320
3. Dell PERC4/DC Dual Channel Ultra320 SCSI RAID (128Mb)  - Raid 10 / 6 HDD 10K SCSI 320

тест iometer - 100% рандом - блоки 8k - либо 100% чтение либо 100% запись - 100 outstanding requests (то бишь очередь)

Вобщем понятно что на небольшом файле играет роль только disk latency - которая для 10k дисков 3 ms - что дает 300 IO/c для 1 диска . В реале я получал даже 400 (когда тестил диски по одиночке). Вобщем на небольшом файле я получал до 2000 IO по чтению  (рандомному) и 900 записи в 3 варианте и где то  1200/400 на 2 предыдущих .  То есть тут все нормально.

Когда рандомные операции по всему диску то еще играет роль average seek - которая для этих дисков 4.7 ms . То есть в итоге 7.7 ms  - должно быть 130 IO для одного диска.

В итоге после тестов на размере всего диска (либо больше 20G)  я имею для всех контроллеров 100 IO и для чтения и для записи - то есть производительность 1 диска (при том что outsatnding requests 100) . Собсно вопрос в том - че это за баг - и сталкивался ли кто нить с этим .

Еще один маленький прикол - 3 контроллер пробовал как на Raid10 так и на Raid50 из 6 дисков - во втором случае на небольшом  файле по чтению получил 2200 IO против 2000 IO на raid 10 . Хотя по логике бы должно быть наоборот.  У 50 рейда 2 диска можно считать что под parity используются и участвуют не на полную .

Политики кеша пробовал менять - собсно кроме writeback ничего особо не влияет - а на чтение и writeback не влиял что логично.

[gs]

Странно это - похоже на глюк. Я на линуксе не пробовал, но на винде такого эффекта точно не видел.

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

[MasterDVDselect]

У 50 рейда 2 диска можно считать что под parity используются и участвуют не на полную .

это не верно  :lol: инфа и парити размазывается по всем дискам
и каждый диск участвует в процессе одинаково.

то что вы описали - это RAID 30 ( 2-а RAID3 в страйпе)

[dagr]

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

Как раз про это я и говорил - на маленьком размере переходы между дорожками небольшие поэтому играет роль только скорость вращения шнинделя - то есть average latency 3 ms - 300IO вполне кореллирует с тем что я увидел . Когда на весь диск - тогда прибавляется average seek - время перехода на другую дорожку - 4.7ms - опять же кореллирует - 130 против 100.

У 50 рейда 2 диска можно считать что под parity используются и участвуют не на полную .

это не верно  :lol: инфа и парити размазывается по всем дискам
и каждый диск участвует в процессе одинаково.

то что вы описали - это RAID 30 ( 2-а RAID3 в страйпе)

Да я знаю что размазывается - чисто интуитивно чусвую что не на полную -)  - просто в случае с небольшим файлом для 5 рейда например из 4 дисков чтение будет немного медленне чем 0 рейд из 4 дисков - потому что из-за парити он займет большее к-во дорожек - и в среднем seek time будет больше . Правда если сравнивать мой случай - 50  и 10 - то как раз в 10 будет большее к-во дорожек  - поэтому это обьясняет  почему я получил на 10 чтение  слегка  хуже

[gs]

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

[dagr]

согласен