Бить массив ЛУНами или не бить?

[MY]

Есть дисковый массив DS 3400, на котором лежат данные двух SQL серверов, один из которых работает для ввода данных, второй - для формирования отчетов. Все дисковое пространство массива выделено под RAID10, побитый ЛУНами на диски, которые уже используются самими инстанциями MS SQL 2000. На обоих серверах имеется 12 баз данных, к которым подключено около 500 пользователей (на втором лишь формируются отчеты). Так как, судя по счетчикам, полученных Perfmon'ом, дисковая система основного сервера не справляется с нагрузкой (Avg. Disk Queque Length достигает величины 500 и более), принято решение докупить полки с дисками. Вопрос такой - имеет ли смысл создавать отдельные RAID под базы данных, обращение к которым наиболее интенсивное, или же создать (или увеличить имеющийся) RAID и побить его ЛУНами?

[Stranger03]

Величина в 500 единиц очень большая. Считайте что на две единицы нужен один диск. В итоге получим цифру в 250 штук дисков. ИМХО вам надо не полки к слабенькой ДС3400 покупать, а смотреть в сторону ДС4700 или лучше ДС4800. Ну и плюс как-то с программерами говорить. Поскольку только тупой набивкой железа здесь проблему не решить.

[Tert]

Я бы начал с увеличения ОЗУ на сервере под кэш SQL.
А уже потом, исходя из установившейся очереди, добавлял бы дисков.

[MY]

Прошу прощения - 500 и более - это максимальное значение Avg. Disk Queque Length. Анализ же логов перфмона показывает периодические пики выше 50. Насколько я понимаю, они являются результатом многочисленных одновременных обращений до массива, на котором лежат 12 баз данных SQL. Уменьшится ли очередь дисков, если распределить файлы баз данных по двум и более RAID массивам, или же производительнее будет система с одним массивом?

[Stranger03]

"MY"
Поскольку у вас есть две задачи, основная база и отчеты (видимо аналитика), то имеет смысл докупить корзину, сделать две рейдргуппы. Одна на основные базы, вторая на аналитику. Как то так. На даже максимальное значение в 500 единиц показывается, что периодически (видимо в момент отчета) возникает катастрофическая нагрузка. Вот ее стоит выделять (аналитику видимо).

[Stranger03]

Ну и коллега правильно подсказывает, соберите вы лучше счетчики и зашлите сюда. А там уже точно подскажем, а не будем тыкать пальцем в небо.

[MY]

Спасибо за ответы!

Все-таки я не понимаю - если выделить один из дисков в отдельный массив, станут обращеня к массивам параллельными по времени, или же логика массива сама распараллелит все обращения?

[Stranger03]

"MY"
Вы бы лучше сохранили счетчики в формате перфоманс монитора. Так не очень удобно.

[MY]

"MY"
Вы бы лучше сохранили счетчики в формате перфоманс монитора. Так не очень удобно.

Боюсь, что не совсем понял - какой его формат является родным Двоичный файл?

[Stranger03]

Боюсь, что не совсем понял - какой его формат является родным Двоичный файл?

Лог файл, у него расширение blg

[Stranger03]

Я просто чего-то не догоняю. Почти во всех этих файликах средняя очередь на дисках равна 0.

[a_shats]

Надо бы счетчики Disk Reads/sec и Disk Writes/sec, Avg. Read Queue Length, Avg. Write Queue Length.
Ну и по конфигурации массива - сколько винтов, какой RAID, как LUNы побиты...
И - соберите, пожалуйста, счетчики одним файлом, не надо по каждому LUNу в отдельный файл, неудобно смотреть.

Есть, правда, подозрение, что ситуация называется "А вы, друзья, как ни садитесь..."  :D  В смысле - тупо не хватает винтов. Причем - не хватает очень серьезно.
Что до собственно вопроса - имея менее 15-16 винтов заморачиваться нарезанием отдельных массивов, имхо, смысла мало. Вы просто отберете производительность у более нагруженных баз - да и все.

[MY]

Некоторое время потребовалось собрать счетчики, с пиковыми нагрузками...
Конфигурация массива такая: на полке IBM DS3400 с 12-ю дисками SAS 15000 RPM 300 Gb создан Raid5. Лунами наделены диски S (базы данных основного SQL сервера), T (базы SQL сервера отчетов), N и U с архивными базами, которые используются редко (по логам это видно). Остальные диски - побитый лунами устаревший SANblock, нагрузка на который невилика, но за счет которого производительность не увеличить. Решение докупить 3 полки к DS3400 с 36-ю дисками должно решить проблему с очередью на чтение, но как распределить эти диски для достижеия максимальной производительности? Да так, чтобы иметь запас производительности хотя бы на год - DS3400 куплена буквально в декабре...
PS: увеличение памяти на главном SQL уже понято как неизбежность

[a_shats]

Я правильно понимаю, что в логе собраны счетчики только с LUN'ов на массиве ?
На томе S: лежит база, верно ?
Так вот: 3527 c копейками Disk Reads/sec  max - это для 12 винтов ОЧЕНЬ много.  Они боле 1800 IOps давать в жизни и не обязаны (настолько больше вышло потому, что из кэша массива явно).
Соотношение 70/30 чтения к записи говорит о том, что не хватает ОЗУ SQL-серверу - наиболее часто читаемые данные БД туда не лезут.
Очередь на чтение вообще сурова.

Рекомендую
- увеличить ОЗУ на сервере SQL минимум до 50% объема БД, в идеале до 100%, если есть такая возможность
- прикупить еще минимум полку к DS3400. Минимум - потому что убить средние нагрузки так можно, но пиковые уже не получится.

P.S. И было бы неплохо вынести аналитику с этого массива куданить, пусть даже на менее мощное, все же в отличие от транзакционной базы аналитикам плюс минус 5 минут не роляет, а пики нагрузки они создают аццкие

[MY]

Даже обидно становитя - аналитика то "вся" вынесена:) второй сервер, судя по логам, откровенно простаивает. Что же касается увеличения оперативки, то даже при увеличении памяти до 10% от объема бд требуется докупить десятки гигабайт. Только закупом железа в этом случае не обойтись - это понять можно из постов выше. Спасибо за ваше время и ответы!:)