Ситуация следующая. Имеем учетную систему на базе 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 (некогда даже о таком не слышал ранее - всегда только про счетчики через профайлер).

Я пришел к тому что результаты DBCC MEMORYSTATUS для меня полный лес и никакого просвета. В документации все описано, но я абсолютно не понимаю какие должны быть оптимальные значения и к чему должны стремиться чтобы понять где у меня узкие места по памяти.

Кто-то может помочь указать явную(ные) проблемы? Буду премного благодарен.

У меня Win2003R2 SP2 64bit и MS SQL Server 2000 Enterprise Edition SP3

Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

Сервер обновлялся и настраивался три года назад мною и ориентиром было чтобы счетчик Доступно МБ в профайлере показывал 12 Гб памяти. Он это и показывает. Теперь подробнее.

sp_configure 'awe enabled'
возвращает
minimum 0, maximum 1, config_value 0, run_value 0

Получается что AWE не включен.

В boot.ini никаких ключей PAE 3GB нет.

Я правильно понимаю что AWE выключен и PAE выключен. Как тогда профайлер показывает 12 Гб?

Насколько я понял что стормозил - в 64bit-ной Win2003 не нужно включать ключ PAE в boot.ini.

Осталось разобраться с AWE.

Включил AWE. Теперь по счетчику "Доступно МБ" память упала с 12Гб до 3Гб. И не поднимается. Хотя min 9Гб, max 12Гб.

Ну теперь я вообще ничего не понимаю.

Может ли врать счетчик "Доступно МБ"? Как его проверить?

Предвидя возможный вопрос по закреплению страниц в памяти.
Пользователь, под которым запускается SQL Server - это администратор домена и в Локальной политике в Назначении прав пользователя в Закреплении - он есть.

Buffer Distribution (Buffers)

Stolen -3593
Free 1070
Procedures 77095
Inram 0
Dirty 9081
Kept 0
I/O 0
Latched 804
Other 1451543

Buffer Counts (Buffers)

Commited 1536000
Target 1536000
Hashed 1461428
InternalReservation 212
ExternalReservation 0
Min Free 512

Интересный момент, что на аналогичном сервере (резервный)

ScareCrowавторOther 1451543
это примерно
11,07439422607422 гиг буферов. поздравляю.
Other. These are committed pages that do not meet any of the criteria mentioned earlier. Typically, the majority of buffers that meet this criteria are hashed data and index pages in the buffer cache.
посмотри наконец счетчик Total Server Memory


Хм. Счетчик не изменился.



Ну и мало ли вдруг что-то прояснит

ScareCrow,

Да, действительно похоже что память сожрана, но счетчик упрямо показывает 3 гига.

ScareCrowне тот счетчик. ищи там раздел MS SQL

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

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

1. Сначала была добавлена память. Во первых были задействованы 12 Гб из 16-ти имеющихся вместо четырех, которые (к моему стыду) были задействованы ранее.
2. Переведены на гигабитную сеть все пользователи, которые работают с тяжелыми или требующей большой производительности операциями типа учета документов, формирование сложных документов, построение сложных отчетов.
3. Всем этим пользователям (предположим их 20 из 70-ти) были обновлены компьютеры со среднестатистического "по больнице" Celeron 2.2 512 Гб RAM до I3 2Гб RAM.
4. После этого возникло некоторое облегчение. Т.к. процесс происходил далеко не за один день - изменения мало были заметны, но если сравнить с тем что было изначально - стало чуть стабильнее (меньше блокировок, меньше подвисаний - да и вообще приятнее работать пользователям), хотя скорость работы впринципе визуально не изменилась.
5. Были добавлены еще 16 Гб памяти. Итого сейчас используется 29 Гб, т.е. количество буферов как и рекоммендовали выше доведено до 3 млн.
6. После этого стало еще стабильнее.
7. Приобретена дисковая полка и теперь дисковая система в отличии от того, что было имеет следующую структуру:
Первый контроллер
C: - RAID 1 - 2x72 Гб SAS 15K - система
E: - RAID 1 - 2x200 Гб SSD MLC - самый ненагруженный (судя по статистике) кусок БД
F: - RAID10 - 4x72 Гб SAS 15K - Лог-файл
Второй контроллер
G: - RAID10 - 4x72 Гб SAS 15K - tempdb
Третий контроллер (полка)
K: - RAID10 - 14x146 Гб SAS 15K - файлы БД кроме того, что лежит на E:
Само собой кэширование, память и батарейки везде. 50% чтение, 50% запись.

8. После этого работа стала еще стабильнее, и даже якобы выросла скорость работы процентов на 10-15.

А вот теперь самое интересное.
Вот счетчики состояния среднего по больнице.



Очереди впринципе выше двойки не поднимаются. По картинке не забываем делить на 100 вертикальную шкалу.



Количество обращений к розовому диску (диск К - где лежит БД) впринципе бывает и зашкаливает за 600, но для 14-ти дисков в RAID10 я думаю это вполне уместно с учетом того, что они справляются судя по следующему скрину.



Как я и писал, что судя по среднему времени отклика - диски справляются, т.к. "пила" идет обычно только по розовому диску и не поднимается выше 10 мс.



99% - это самая обычная картина использования памяти. Т.е. почти все что нужно умещается в оперативке.



Ну и проц впринципе особенно не напрягается.


Вот вроде бы все хорошо и замечательно - сервер пустой, машины пользователей не напрягаются.
А где же рост? Ну хоть процентов на 50? (Я уж не говорю "в разы").
Куда дальше рыть?
Как сделать чтобы скорость выполнения запросов значительно увеличилась?
Учетную систему прошу не ругать, она самая обычная. Просто странно что при значительно проапгрейженном сервере и пользовательских машинах я получил только стабильность и рост скорости около 10%.

iv_an_ru,

Это понятно, но ведь даже если запрос крайне не оптимален, то он должен после такого апгрейда выполняться значительно быстрее, а не только на 10 процентов.

Предположим имеем таблицу без ключей и индексов. Лежит она на диске. Мы делаем курсором пробежку по этой таблице за 500 мс.

Если я сделаю не 1 диск, а предположим 3 диска в RAID0, то (предположим что шины, контроллеры, память и т.п. - все пропускают), то скорость дисковой системы увеличится минимум раза в полтора (в идеале в три, но предположим что в полтора).
Будет ли рост в полтора раза скорости выполнения запроса? Вот не будет.

Вообще в MS SQL заложена функция гибкого торможения. Ее спонсируют производители железа. :)

miksoftKaktus_iv_an_ru,

Это понятно, но ведь даже если запрос крайне не оптимален, то он должен после такого апгрейда выполняться значительно быстрее, а не только на 10 процентов.С чего бы? Если упор происходит в CPU, то ничего не изменится.

И вообще, вы улучшаете систему с точки зрения производительности, а хотите уменьшения времени реакции (что далеко не одно и тоже).

P.S. В Paint-е выставьте размер картинки по-умолчанию поменьше, например, 100*100 пикселей, чтобы не было дурацких белых полей у скриншотов.

Да, с картинками закосячил.

Ну вот вы же видите мою систему - узких мест нет. Проц не загружен, винт не загружен, сеть (не вывел скрины, но всеже) не загружена. Машины пользователей также не шибко загружены.
Че он (сервер) делает? Поидее если нет узких мест система должна работать максимально быстро пока не появится узкое место, на нем она должна и тормозить. Но если у системы нет узких мест? :)