Ситуация следующая. Имеем учетную систему на базе MS SQL Server.
База крутится на DL380 G6. Две корзины по 8 дисков каждая. Каждая на своем контроллере P410 с памятью и батарейкой.
Система RAID1 2xSAS15K
ФайлБД1 RAID10 4xSAS15k
ФайлБД2 RAID1 2xSSD MLC
ФайлБД3 RAID10 4xSAS15k
Log и TempDB RAID10 4xSAS15k

Итого все слоты заняты. Специфика такова, что чтобы что-то изменить в хранилище - нужно ждать останова производства, а это бывает очень редко. Производство круглосуточное. Остановить сервер я могу на час или на два максимум.

Имеем. Все работает нормально, быстро и т.п., но после запуска новой очень сложной системы посекционного учета получили тормоза у всех пользователей, которые работают с этим блоком. За три месяца в программе оптимизировано все что только можно (будем считать что оптимизировать программу уже некуда). Пользователям всем обновлены компьютеры, переведены на гигабит, проведен анализ узких мест.
После этого некоторая стабильность появилась, но нет роста скорости работы. Просто вот выполняется операция 10 секунд, а нужно чтобы выполнялась 1 секунду.
Насколько я могу судить - просто не хватает скорости работы дисковой системы.
Пример. Есть запрос по остаткам - на пустом сервере выполняется 8 секунд, на загруженном в обычном режиме 20, а нужно чтобы выполнялся за 2.

Анализ всех узких мест по счетчикам и т.п. показывает что все ништяк.

Грешу на дисковую систему.
Теперь самое интересное - как с минимальными затратами протестировать - а правда ли что модификация дисковой подсистемы даст значительный прирост производительности.
Самый классный вариант - это взять в опытно-промышленную эксплуатацию СХД на 24xSAS15k, забить ее ими, сделать RAID10, положить туда базу и посмотреть что произойдет с реальной производительностью. Если она действительно скаканет - купить эту полку. Подкинуть полку и перенести на нее базы это дело нехитрое и не требует останова производства.

Имеется DL380 G7 (резервный сервер). На нем винты под систему 2xRAID1, плюс скоро придут еще 8xSAS15K.
Общаюсь сейчас с поставщиком каким образом сделать чтобы G7 стал для основного G6-ого полкой чтобы протестировать скорость работы.
Покритикуйте пожалуйста меня. Может быть есть какие-то другие способы для моего случая потестировать скорость работы базы на значительно бОльшем количестве шпинделей?

Еще раз обращаю внимание что интересует рост скорости работы скажем так в десять раз, поэтому предложения по поводу того чтобы разложить Log и TempDB на разные диски - не интересны (по ним кстати по счетчикам и анализам проблем нет). Нужно что-то реально действенное, но дешевое на этапе тестирования. Купить мы можем и не дешевое, но нужно понять - будет ли реальный рост.

miksoftKaktus_,

Имхо, нужно было это в подфорум по MS SQL писать.
По моему опыту, когда говорят "в программе оптимизировано все что только можно", то там остался еще изрядный запас по оптимизации. Не обязательно в самой программе, а, может быть, в настройках СУБД.

Я поэтому и акцентирую внимание на том, что программно все что можно - все оптимизировано по максимуму. А даже если где-то и не оптимально, то оптимизация не даст роста производительности на порядок.

База данных является обычной учетной системой с 70-ю одновременными пользователями. Бухгалтерия, производственный учет, логистика и т.п.
Пишу сюда, т.к. интересует именно дисковая система.
В общем сервер сейчас выглядит так:
Объем БД 100 Гб.
Загрузка процессора около 17 процентов
Память - Ввод/Вывод страниц в секунду как и должны быть ноль
Кэш - Процент попаданий при отображении как и должен быть 100 процентов
I\Oпсы - если суммирую обращения чтения и удвоенные обращения записи, делю на количество дисков, то для SSD и не превышает 3000 (Это поидее нормально для HP MLC SSD), а для SAS15K не превышает 300, что для них тоже вроде бы нормально.
Среднее время чтения/записи изредка доходит по некоторым дискам до 15мс, а так 2мс.
Очереди по дискам примерно одинаковые. Подскакиваеют до 20-50 пиками. Пики длиной около 5-7 секунд. Расстояние между пиками около 30 секунд.

Распределение нагрузки по дискам (суточная):

Система RAID1 2xSAS15K - Чтение 12 Гб, запись 0.1 Гб (тут лежит только mdf)
ФайлБД1 RAID10 4xSAS15k - Чтение 700 Гб, запись 5 Гб
ФайлБД2 RAID1 2xSSD MLC - Чтение 1500 Гб, запись 1.5 Гб
ФайлБД3 RAID10 4xSAS15k - Чтение 700 Гб, запись 0.2 Гб
Log и TempDB RAID10 4xSAS15k - LogЧтение 2 Гб, LogЗапись 4 Гб, TempDBЧтение 52 Гб, TempDBЗапись 52 Гб.

Большие объемы чтения связаны с тем, что каждые 15 минут формируется разностный бэкап. Полный делается раз в день. Разностный бэкап делается от 10 секунд первый до 3 минут последний, но не замечено никакой связи снятия разностного бэкапа и скорости работы системы.
Разностный и полный бэкап уходят на сетевой диск.

Итак. Получаем не шибко перегруженную систему (на мой взгляд). И работает она нормально. Но нужен значительный рост производительности на порядок. Опять же - сервер останавливать можно только на 1 час максимум чтобы что-то засунуть/высунуть/проверить.

iv_an_ruKaktus_Большие объемы чтения связаны с тем, что каждые 15 минут формируется разностный бэкап. Полный делается раз в день. Разностный бэкап делается от 10 секунд первый до 3 минут последний, но не замечено никакой связи снятия разностного бэкапа и скорости работы системы.То есть диски и так не напрягаются, раз лишняя задача на отклик не влияет, верно?

Да, получается так. По крайней мере нет тенденции что увеличивается скажем так частота пиков счетчиков в 0,15,30,45 минут каждого часа.

KhodKaktus_Еще раз обращаю внимание что интересует рост скорости работы скажем так в десять раз , поэтому предложения по поводу того чтобы разложить Log и TempDB на разные диски - не интересны (по ним кстати по счетчикам и анализам проблем нет). Нужно что-то реально действенное, но дешевое на этапе тестирования. Купить мы можем и не дешевое, но нужно понять - будет ли реальный рост.

В 10 раз. Вы фантазёр...

1. Сеть гигабитная?
2. Оперативы хватает?
3. Лишнее ПО на сервере установлено?
4. Камень на сервере каой?
5. Статистика по ночам считается?

Сеть гигабитная.
Оперативки 16 Гб. На базу 100 Гб. SQL по счетчикам кушает ее правильно всю.
Лишнего ПО вообще ноль. Только антивирус (авира), которая вообще не замечена в съедании ресурсов.
Процессора два XeonQC E5504 2ГГц
Статистика обновляется по десятку основных таблиц каждую ночь. Хм. А может быть обновлять не по десятку таблиц, а по двум-трем. Т.е. расширить список таблиц, которые считаются основными.

Кстати еще одна проблема специфичная. Реиндекс. Полный реиндекс базы идет 2 часа. А т.к. производство круглосуточное - остановить на 2 часа процесс нельзя. Но реиндекс не панацея и как показывала практика предыдущих лет когда работали не круглосуточно - делает работу более стабильной, но не дает прирост на порядок.

Так вот насчет в 10 раз. Фишка в том, что компания готова платить за этот прирост деньги, но я не могу понять как определить узкое место. А может быть его и нет - может быть просто нужно брать новый мощный сервер с EVA. Но это значительные деньги для компании и компания пойдет на это, но при условии что будет обоснование и не окажется что скорость нового сервера такая же как и у старого.

Дайте EVA на недельку. ;)

Вобщем итого что решили сделать.
1. Купить 16 Гб памяти (сейчас на базу 100 Гб 16 Гб оперативки) и посмотреть что из этого получится. Цена вопроса 16 тыс рублей, поэтому проблем нет.
2. Ведем переговоры по поводу того чтобы взять полку (пусть даже и без винтов) в опытно-промышленную эксплуатацию на недельку чтобы протестировать возможное значительное увеличение количества шпинделей.
3. Пишем на форум о полученных результатах чтобы поделиться положительными ли отрицательными результатами. :)

Ну и параллельно оптимизируем код, хотя и так уже дальше некуда, но совершенству нет предела.

По поводу бэкапа лога - спасибо идею тоже рассмотрю.

G - зеленый RAID10 из 4 SAS 15K - на нем лежит одна из файлгрупп базы
H,J - синиз RAID10 из 4 SAS 15K - на нем лежит лог и темпдб
C - желтый RAID1 из 2 SAS 15K - на нем лежит mdf-ка
E - красный RAID1 из 2 SSD MLC - на нем лежит одна из файлгрупп базы
F - голубой RAID10 из 4 SAS 15K - на нем лежит одна из файлгрупп базы







На этом примере загружена больше всего одна из файлгрупп (зеленый G). Но такая же загрузка бывает и по другим файловым группам Красной E и голубой F.
Приведенный пример является не максимальной (пиковой) загрузкой сервера, а загрузкой чуть больше чем средней, но и не максимальной.

iv_an_ruKaktus_,

16 гигов ОЗУхи, из них винда показывает выделенных только 5 гигов. Вам точно не надо увеличивать размер дискового буфера в скульсервере? Гигов на пять, для разминки?

Да на самом деле SQL видит памяти 12 Гб.

iv_an_ruKaktus_,

Что возвращает


?

Ну и DBCC MEMORYSTATUS до кучи

Первый запрос не работает - может быть потому что у меня MS SQL Server 2000. (Видимо там нет sys.dm_os_memory_clerks

По второму

Buffre Distribution (Buffers)
Stolen 7201
Free 1661
Procedures 17264
Inram 0
Dirty 3593
Kept 0
I/O 2
Latched 1590
Other 433961

Buffer Counts (Buffers)
Commited 465272
Target 465272
Hashed 439146
InternalReservation 1782
ExternalReservation 190
Min Free 960

Procedure Cache (Value)
Commited 465272
Target 465272
Hashed 439146
InternalReservation 1782
ExternalReservation 190
Min Free 960

Dynamic Manager Memory (Buffers)
Stolen 24432
OS Reserved 7056
OS Committed 6997
OS In Use 6623
General 5373
QueryPlan 19928
Optimizer 0
Utilities 138
Connection 818

Glocal Memory Objects (Buffers)
Resource 4237
Locks 1709
XDES 275
SQLCache 697
Replication 2
LockBytes 2
ServerGlobal 52

Query Memory Objects (Value)
Resource 4237
Locks 1709
XDES 275
SQLCache 697
Replication 2
LockBytes 2
ServerGlobal 52

Optimization Queue (Value)
Optimizing 0
Waiting 0
Available 32
Maximum 32

iv_an_ruKaktus_Buffre Distribution (Buffers)
Stolen 7201
Free 1661
Procedures 17264
Inram 0
Dirty 3593
Kept 0
I/O 2
Latched 1590
Other 433961

Это по какому обменному курсу буфера к байту похоже на 12 гигов? При 8Kb буферах --- совсем не похоже.

Мне трудно судить, я никогда таким образом память не анализировал. Я глядел чтобы счетчик памяти показывал сколько нужно, плюс ввод/вывод страниц в секунду чтобы стремился к нулю. Сейчас буду глядеть что значат результаты, которые получились с помощью DBCC MEMORYSTATUS (некогда даже о таком не слышал ранее - всегда только про счетчики через профайлер).