Возможности повышения производительности сервера баз данных MS SQL 2008
был предложен вариант мониторинга SQL сервера на предмет наличия узких мест. в результате теста получил
wait type    wait time    percentage
***total***    176672519.0    100.0
XE_DISPATCHER_WAIT    27270592.0    15.4
LAZYWRITER_SLEEP    17945556.0    10.2
XE_TIMER_EVENT    17970354.0    10.2
LOGMGR_QUEUE    17942674.0    10.2
REQUEST_FOR_DEADLOCK_SEARCH    17951880.0    10.2
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    17941836.0    10.2
FT_IFTS_SCHEDULER_IDLE_WAIT    17821044.0    10.1
CHECKPOINT_QUEUE    17727624.0    10.0
SLEEP_TASK    9025843.0    5.1
BROKER_TO_FLUSH    8974737.0    5.1
SOS_SCHEDULER_YIELD    3634747.0    2.1
LCK_M_S    646552.0    0.4
ASYNC_NETWORK_IO    745808.0    0.4
SLEEP_BPOOL_FLUSH    91609.0    0.1
PAGELATCH_EX    159411.0    0.1
LCK_M_IS    166484.0    0.1
LCK_M_IU    131419.0    0.1
LCK_M_IX    109600.0    0.1
WRITELOG    193682.0    0.1

тест Гилева показывает результат от 5 до 7.
Сервер 1С и сервер SQL разнесены на разные машины
SQL сервер 2008 r2 sp2 win 2008 все это на виртуальной машине под Hyper-V.
что можно сделать, что бы тест показывал хотя бы 15-20 ?

купить другую машину.

(1) очень аргументированный ответ

вообще возможна-ли нормальная производительность sql на виртуальном сервере?
http://wiki.vm4.ru/sql можно попробовать это.

(0) У меня тоже SQL 2008 и тоже низкий результат, я немного покопал на форуме - походу это такая фича 2008 SQLа, что делать толком никто не знает, разве что поставить 2005ый, там покажет в разы больше.

(3) вот спасибо, меня давно терзают смутные сомнения по поводу нормальной производительности SQL на виртуальном сервере

(5) не факт, если все нормально настроено - летает

(6)как нормально настроено? ссылки может приведете, что надо настраивать для максимальной производительности?

(6) каким именно настройкам следует уделить внимание, где возможны узкие места? на сколько важно подклчючать физический диск в виртуальной среде, а не виртуальный диск (дисковая подсистема не загружена)

мое твердое убеждение что скуль ни в коем случае нельзя ставить на виртуалку.

глаавная проблемма - скуль не понимает где физическая память а где своп, по этому нарываемся :)

а вообще судя по (0) у тебя точно криво настроен сам скуль и регламенты на нем.

распиши регламенты баз для начала

REQUEST_FOR_DEADLOCK_SEARCH - ну ни как не должно быть более 0.1%

регламентные операции настроены в соответствии с http://kb.1c.ru/articleView.jsp?id=13

обновление статистик - раз в день в час ночи
дефрагментация индексов - раз в день в 3 часа ночи
реиндексация - раз в неделю в 4 ночи

модель восстановления - симпл
бэкап средствами sql раз в день ночью

(12) закрыт раздел

обновление статистики делается? как часто? именно на основании статистики и работает вся оптимизация запросов.

я обновление статистики делаю раз в час

УПП 1.3.25.1 8.2.15.301

предприятие порядка 6000 сотрудников
в момент замера расчетчики проводили расчет и начисление зарплаты по отделам

а вообще если памяти всего 24 гига - то это ОЧЕНЬ мало (тем более что делим на виртуалки)

даже простой документооборот нормально работает >=64 гига, а про УПП помолчу

(18) в данный момент на эту виртуалку выделено 16 Гб
sql отдано 12 - остальное под систему
сервер 1С живет на отедльном сервере

(18) какими показаниями счетчкиво можно определить что мало памяти?

(20) на железной машине (а не на виртуалки) длину очереди к диску, если более 0.5с - то мало, если 5-10с - то афигительно мало

и все же остается открытым вопрос по тесту Гилева, почему он показывает такую низкую скороксть записи документов

(22) на виртуалках большенство счетчиков и статистик показывают полную лажу, по этому делай замеры на железном сервере, выяви чего у тебя с железом...

потом смотри чего с виртуалками, и уже потом софт.

на виртуалках очень сложно отделить проблеммы софта от проблемм с железом...

виртуалки подходят для чего угодно кроме субд

(23) Сисадмины утверждают, что "железо не нагружено", и "проблем с виртуалкой и СУБД быть не может, потому что связка Оракла и СМАРТИМ замечательно работают на виртуальных машинах"

Memory \ Pages/sec
Pocessor [_Total] \ %Processor Time
System \ Processor Queue Length
Phisical Disk \ Avg. Disk Queue Length
Network Interface \ Bytes Total/sec

этих счетчиков будет достаточно?

главное вот это

Phisical Disk \ Avg. Disk Queue Length

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

только ведь админ скажет что это не память а диск тормозит, но ты не верь :)

Avg. Disk sec/Read
Avg. Disk sec/Write
на каждые диски
вместо Phisical Disk \ Avg. Disk Queue Length

(27) ты не прав

Avg. Disk sec/Read
Avg. Disk sec/Write

покажут реальную проблемму с дисками, а

Phisical Disk \ Avg. Disk Queue Length

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

(28) средняя длина очереди диска 0.002

пик - 0,102

а в чем собственно проблема заключается? что озаботились производительностью SQL?

средняя длина очереди диска (30 мин) средняя - 0.184 максимум - 18.894

(31) причина - жалобы пользователей во время расчета зарплаты
постоянная транзакция, отчет "расчетные листки организаций" по отделу - время формирование 5-10 мин

проверка на тесте Гилева - отвратительный результат

(32) делай скриншет максимум - 18.894 и админу в морду,

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

сейчас запустили замер - на 2 часа

включили счетчики из (25)

(35) со  своей стороны постарайся сопоставить момент возникновения пика очереди с действиями пользователей в программе, может чего полезное увидешь.

Как объяснить тесты Гилёва
на VMware   3 виртуальных сервера (рабочая станция, 1С, SQL), результат 27
комп с SATA дисками, 5к скорость вращения, рейда нет.

И результат 20 - 3 железных сервера, двухпроцессорные, БД хранится на iSCSI.

Железо плохое?  Или виртуальные системы имеют право на жизнь?

(38) у нас результат 5-7

(33) а параметры серверов SQL  и 1С  какие ? вкл счетчики

Avg. Disk sec/Read
Avg. Disk sec/Write
Memory \ Pages/sec

Avg. Disk sec/Read средняя - 0.073 максимум - 15.419
Avg. Disk sec/Write средняя - 0.110 максимум - 18.894

(38) Тест Гилева показывает какое количество обрабатывает система при последовательной записи/проведении документа движения денежных средств за единицу времени

Текущая длина очереди диска  средняя - 0.142 максимум - 27
Пики всех графиков совпадают

на SQL один диск чтоле? vmdk? а Memory \ Pages/sec что показывает?

я по дефолту все установил и померял у себя
W2008R2 + SQL2008R2
на железном сервере - 17
на этом же сервере на Hyper-V - 17

на сервере слабый дисковый контроллер

http://s56.radikal.ru/i152/1206/ee/07ef7a16815c.jpg

(45)на SQL 10 райд

(47) ну у меня тоже 10-й райд

(47) кеш на контроллере точно включен? кажись нет

из скрина нехера непонять.
если рэйд то очередь нужно делить на кол-во дисков в рейде.

(50) что значит делить на количество дисков?

(51) ты зря счетчики поставил на тотал, нужно на каждый диск/райд по отдельности, тогда можно будет отделить очередь создаваемую

2 Raid1 - система (Server 2008 Standart x64)
2 Raid1 - файлы бд
2 Raid0 - TempDB
2 Raid1 - файлы журналов транзакций

но если пики совпадают - значит сто пудово память докупать

(52) если я прав у тебя очередь большая только на
2 Raid1 - система (Server 2008 Standart x64)

и возможно на
2 Raid0 - TempDB



очередь к файлам и логом скуля должна быть в норме

(52) (53)
на сколько я знаю - вся система на одном(1) райде, который общий для всего, а кроме того - диск в виртуальной среде - виртуальный и динамический

(54) тогда не ип.... мозг, делай замеры на базовом сервере а не на виртуалке...

если прав нет - иди к админу... сколько можно говорить - счетчики на виртуалке показывают фигню....

это замер админа с реального сервера

Memory \ Pages/sec - какому счетчику в русской раскладке соотвествует?

\Память\Обмен страниц/сек

подпишусь.

А скуль отжирает всю предоставленную память в момент нагрузки?

все замеры выполнены на реальном сервере.
замер нагрузки сегодня утром http://ifolder.ru/30994232
замер нагрузки вчера с 14 до 16 http://ifolder.ru/30994234
первый замер http://ifolder.ru/30994239

(60) Скуль отжирает с удовольствием всю память которую ему дают - все 12 Гб

(61) что-то ЦП вообще около 0 нагружен, похоже на то что только 1 ядро работает на всех...

закажи у админа
1. загрузку ЦП по ядрам отдельно



и сравни пики (у тебя обмен страниц а нужно ошибки страниц), это будет показатель использования свопа
1. ошибки чтения страниц памяти
2. Длина очереди диска

(61) по этим счетчикам ничего толкового.
нужны счетчики

Avg. Disk sec/Read
Avg. Disk sec/Write
покажут производительность  дисковой подсистемы

Memory \ Pages/sec
покажет достаточно ли ОЗУ

замер проводить в момент наибольшой активности или в момент выполнения "тяжелых" операций.

а вообще в помощь
http://www.sql.ru/articles/mssql/03121001perf_counters.shtml#51

(63) новый замер http://www.fayloobmennik.net/1957027

(65)
очень прикольно
------------------------------------------------------------------------
у тебя камень 0 загружен исключительно ядром, это видно по кореллякции его графика с сетевой загрузкой,

камень 1 у тебя используется виртуалками и загружен максимум на 10%, вероятно он 8 ядерный и грузится только 1 ядро

советую покопатся в настройках виртуализации (возможно машина триальная и там действует ограничение по количеству камней !!!!)

------------------------------------------------------------------------

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

Советую докупить память (хотя совсем явных признаков по нехватки памяти нет)


------------------------------------------------------------------------
сетевой интерфейс 2 дает очень прикольную пилу, вероятно это какая-то система управления сервером? Просто интересно чего это за шляпа :)

(66) по результатам пмереговоров было принято решение о переезде на физический сервер - по результатам напишу сюда же

всем спасибо за помощь

(66) ответ админа по сети
: вообще там 4 интерфейса
: по одному на каждую виртуалку и один управление гипервизором