Разнесение SQL и Citrix 1C 7.7

[a_shats]

Про Outstanding I/Os я уже написал, 4 - это вообще никак. Тестите при 100 хотя бы.
Объем тестируемой области - 150 МБ - сравним с кэшем контроллера, т.е. тоже очень мал.
Отсюда  и результаты.

[greensleeve]

Извините, а как из скриншота следует что Outstanding I/Os = 4 ?
Исходя из Вашего опыта, какой объем тестируемой области лучше задать для данного случая? 500,1000 ? спасибо

[a_shats]

Managers=4, по умолчанию Outstanding I/Os каждого = 1
Объем тестируемой области, если хотите близко к задаче = объем БД+объем логов. Но - заведомо больше кэша RAID-контроллера. В разы.

[greensleeve]

ага! странно, что в исходнике не указан такой важный параметр как объем тестируемой памяти...
http://www.storagereview.com/articles/2 ... dBM_5.html
только что получил очередные результаты perfmon за рабочий день
avg. disk queqe length - avg = 0.26 , max = 26
% disk read time - avg = 11 , max = 451
% disk write time - avg = 10 , max = 2638
может быть, я ошибся с характером нагрузки?

[a_shats]

Опять же, по умолчанию объем тестируемой области - на весь объем массива.

[greensleeve]

эмм...характер нагрузки...

[a_shats]

Это на какой конкретно конфигурации сервера ?
Еще нужны
Disk Writes/sec
Disk Reads/sec

[greensleeve]

на первой, Которая serveRaid6 raid5x15KxSCSI 36,7
Запустил счетчики....

[a_shats]

Есть подозрение, что Вам не хватает производительности дисковой именно в силу того, что у Вас RAID5, а не RAID10...
Хотя подожду значений Disk Writes/sec и Disk Reads/sec.
Может - просто уже винтов не хватает.

[greensleeve]

Данные за час...
disk reads/sec avg=17 max=191
disk writes/sec avg=31 max=205

[a_shats]

Нее, это очень немного. RAID10 проблему решит однозначно.

[greensleeve]

Подождите-подождите, не так быстро, давайте по пунктам
1) Исходя из % disk read time - avg = 11 , % disk write time - avg = 10
можно сказать, что нагрузка-то по чтению/записи идет 50/50. Да?
2) max % disk write time в 5 раз больше max % disk read time
поэтому Вы сказали за RAID10 . Правильно?
3) average Total disk operations/sec = 31+17 = 48. насколько я знаю, диск SCSI 15K дает около 80. Если брать "пики" по чтению 200, то они должны легко переносится дисковой 80x5 = двойной запас, а вот если рассмотреть "пики" по записи 200, то дисковая затыкается за счет "упадка" RAID5 80/4 = 20 - на порядок меньше. Is it right?
4)  IOmeter дал 11 MB per second, по-моему это дико мало. И какая формула соотносит Mb/sec и total disk operations/sec?
(Спасибо Вам за помощь и терпение!)

[a_shats]

1) 2) На % в данном контексте можно просто не обращать внимание, смотрите именно живые IOps'ы на запись и чтение.
3) Не совсем Одиночный диск 15К в пике дает до 450-500 IOps, в жизни порядка 200-250. Но вывод - правильный, RAID10 для такой нагрузки (с преобладанием записи) эффективнее.
4) Это нормально для малого размера блока. Вообще, для Вашей задачи гораздо важнее IOps, чем MB/s.

[greensleeve]

1,2) Но ведь мне надо знать характер нагрузки по соотношению чтение/запись - я прав в том, что исходя из % disk read time - avg = 11 , % disk write time - avg = 10 считаю характер нагрузки 50/50?
Cмотреть живые IOPs где? - в IOmeter'e (значение 711)? Но мне как раз и надо ставить характер нагрузки перед измерением...
3) Опаньки...То есть если взять константу 200, то дисковая сейчас отдыхает на чтении т.к. 200<<200x5, но затык по записи все равно присутствует 200>>200/4....Понятно, спасибо. Для общего развития, а какие IOPS даст в жизни одиночный диск 10К (может 130)?
4) Насколько я знаю, SQL работает с так называемыми экстентами по 64Кб (что, кстати, отлично укладывается в Ваши рекомендации про размер stripe size под СУБД, ) Возможно и тест IOMeter правильнее запускать с блоком 64К??? Не понял Вашей фразы "важнее IOps, чем MB/s" - разве эти величины не линейно зависимы? Если это FAQ, где бы почитать...

[Tert]

greensleeve

разве эти величины не линейно зависимы?

С блоками одного размера зависимость конечно очень простая:
MB/s=IOPS*k,
где k - размер блока в мегабайтах (например, для 64К блока - 0,0625 МБ).
Если там много разных блоков, то
MB/s = summa [f(i)*k(i)] * IOPS,
где f(i) - параметр Percent of Access Specification/100 для конкретного блока k(i).