Странности в поведении Axapt'ы

[Sergey Petrov_imported]

Для начала - спасибо Вам за оперативность!

В том и дело, что основной ресурс, который в тёмные времена у нас больше всего занят - это процессоры. По I\O - особых затыков не видно. Очередей постоянно висящих не наблюдается. По сети тоже вроде затыков нет. Есть подозрение, что наш SQL Server как-то не так настроен. Может быть, какие-то сессии оставляют свои следы, которые копятся, а после перезагрузки попросту сбрасываются и система как новенькая. Вроде бы с точки зрения нашего программиста всё оптимизировано.

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

Насчёт настроек SQL Server'а мы пока начали обновлять статистику по индексам. Раньше она была в автоматическом режиме. Хотим выяснить, поможет ли это. Переиндексация базы данных к какому-либо значительному приросту производительности не привела.

Основной вопрос: можно ли как-нибудь оценить оптимизированность запросов к базе данных (и вообще оптимизированность нашего SQL Server'а) и выяснить, не кроются ли проблемы в пользовательских настройках (есть у нас такое подозрение, однако замечено, что сама Axapta стартует нормально и вешается уже на всяческих операциях, связанных с базой данных).

[mazzy]

Цитата:

Сообщение от Sergey Petrov

В том и дело, что основной ресурс, который в тёмные времена у нас больше всего занят - это процессоры.

<{POST_SNAPBACK}>

Процессоры? На файлсервере? На СКЛ сервере?
Извините за дурацкий вопрос - какой режим у дисков? Не PIO какой-нибудь?

Цитата:

Сообщение от Sergey Petrov

Основной вопрос: можно ли как-нибудь оценить оптимизированность запросов к базе данных (и вообще оптимизированность нашего SQL Server'а) и выяснить, не кроются ли проблемы в пользовательских настройках (есть у нас такое подозрение, однако замечено, что сама Axapta стартует нормально и вешается уже на всяческих операциях, связанных с базой данных).

<{POST_SNAPBACK}>

http://axapta.mazzy.ru/lib/indexhints/
http://axapta.mazzy.ru/lib/dbgrowthsolution/
http://axapta.mazzy.ru/lib/adjustment/
и далее по ссылкам.

[Sergey Petrov_imported]

Цитата:

Сообщение от mazzy

Процессоры? На файлсервере? На СКЛ сервере?
Извините за дурацкий вопрос - какой режим у дисков? Не PIO какой-нибудь?

<{POST_SNAPBACK}>

Процессоры перегружены на сервере SQL.
Диски работают через двухканальный RAID-контроллер LSI AcceleRAID 320-2 (U320 SCSI). На одном канале корзина с 5 дисками Seagate Cheetah 10K.6 (ёмкость 146.8 Gb, скорость 10000 rpm), на другом - корзина с 5 дисками Seagate Cheetah 15K.4 (ёмкость 36.7 Gb, скорость 15000 rpm). В первой корзине 3 из 5 дисков объединены в RAID-0 массив (на нём логи), 2 оставшихся под систему и SQL Server со служебными базами. Во второй корзине все 5 дисков объединены в RAID-0 (на нём база). Думаю, что PIO у нас не используется.

[mazzy]

Цитата:

Сообщение от Sergey Petrov

Думаю, что PIO у нас не используется.

<{POST_SNAPBACK}>

Цитата:

Сообщение от Sergey Petrov

Спасибо Вам за помощь (кстати, совсем забыл поблагодарить)!

Кстати, вы можете добавить респект в сообщении, которое вам понравилось.
Для этого нажмите + в строчке Респекты: под подписью участника.

[Vadik]

Цитата:

Сообщение от Sergey Petrov

В том и дело, что основной ресурс, который в тёмные времена у нас больше всего занят - это процессоры. По I\O - особых затыков не видно. Очередей постоянно висящих не наблюдается. По сети тоже вроде затыков нет.

<{POST_SNAPBACK}>

Лично я Вам как администратор администратору верю, но все же..

select @@version ?
dbcc sqlperf(waitstats) ?
показатели perfmon (процессор, очередь на диске, batch requests/sec) ?

Цитата:

Для хранения данных используется дисковый массив RAID-0 из 5 дисков. Логи хранятся на отдельном дисковом массиве RAID-0 из 3 дисков.

Ужас..

[Sergey Petrov_imported]

Цитата:

Сообщение от Vadik

select @@version ?

<{POST_SNAPBACK}>

Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright © 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1, v.1433)

Цитата:

Сообщение от Vadik

dbcc sqlperf(waitstats)

<{POST_SNAPBACK}>

Wait Type Requests Wait Time Signal Wait Time
MISCELLANEOUS 20.0 0.0 0.0
LCK_M_SCH_S 0.0 0.0 0.0
LCK_M_SCH_M 0.0 0.0 0.0
LCK_M_S 15.0 1486.0 0.0
LCK_M_U 30.0 159266.0 156.0
LCK_M_X 0.0 0.0 0.0
LCK_M_IS 9.0 111967.0 0.0
LCK_M_IU 2.0 5860.0 0.0
LCK_M_IX 18.0 365234.0 0.0
LCK_M_SIU 0.0 0.0 0.0
LCK_M_SIX 0.0 0.0 0.0
LCK_M_UIX 0.0 0.0 0.0
LCK_M_BU 0.0 0.0 0.0
LCK_M_RS_S 0.0 0.0 0.0
LCK_M_RS_U 0.0 0.0 0.0
LCK_M_RIn_NL 0.0 0.0 0.0
LCK_M_RIn_S 0.0 0.0 0.0
LCK_M_RIn_U 0.0 0.0 0.0
LCK_M_RIn_X 0.0 0.0 0.0
LCK_M_RX_S 0.0 0.0 0.0
LCK_M_RX_U 0.0 0.0 0.0
LCK_M_RX_X 0.0 0.0 0.0
SLEEP 109082.0 4767016.0 4755491.0
IO_COMPLETION 1529.0 16155.0 0.0
ASYNC_IO_COMPLETION 4.0 359.0 0.0
RESOURCE_SEMAPHORE 0.0 0.0 0.0
DTC 0.0 0.0 0.0
OLEDB 3.0 705.0 0.0
FAILPOINT 0.0 0.0 0.0
RESOURCE_QUEUE 139793.0 1.3943909E+7 4742497.0
ASYNC_DISKPOOL_LOCK 33.0 0.0 0.0
UMS_THREAD 0.0 0.0 0.0
PIPELINE_INDEX_STAT 0.0 0.0 0.0
PIPELINE_LOG 0.0 0.0 0.0
PIPELINE_VLM 0.0 0.0 0.0
WRITELOG 75795.0 138961.0 8449.0
PSS_CHILD 0.0 0.0 0.0
EXCHANGE 3.0 0.0 0.0
XCB 0.0 0.0 0.0
DBTABLE 0.0 0.0 0.0
EC 0.0 0.0 0.0
TEMPOBJ 0.0 0.0 0.0
XACTLOCKINFO 0.0 0.0 0.0
LOGMGR 0.0 0.0 0.0
CMEMTHREAD 7260.0 1100.0 1036.0
CXPACKET 39727.0 2993241.0 25708.0
PAGESUPP 594.0 468.0 280.0
SHUTDOWN 0.0 0.0 0.0
WAITFOR 0.0 0.0 0.0
CURSOR 0.0 0.0 0.0
EXECSYNC 0.0 0.0 0.0
LATCH_NL 0.0 0.0 0.0
LATCH_KP 0.0 0.0 0.0
LATCH_SH 0.0 0.0 0.0
LATCH_UP 17.0 219.0 0.0
LATCH_EX 1751914.0 994243.0 199612.0
LATCH_DT 0.0 0.0 0.0
PAGELATCH_NL 0.0 0.0 0.0
PAGELATCH_KP 1.0 0.0 0.0
PAGELATCH_SH 4106.0 2500.0 328.0
PAGELATCH_UP 821.0 2183.0 387.0
PAGELATCH_EX 10914.0 2309.0 1263.0
PAGELATCH_DT 0.0 0.0 0.0
PAGEIOLATCH_NL 0.0 0.0 0.0
PAGEIOLATCH_KP 0.0 0.0 0.0
PAGEIOLATCH_SH 107398.0 671708.0 2397.0
PAGEIOLATCH_UP 150.0 1172.0 0.0
PAGEIOLATCH_EX 19551.0 180694.0 499.0
PAGEIOLATCH_DT 0.0 0.0 0.0
TRAN_MARK_NL 0.0 0.0 0.0
TRAN_MARK_KP 0.0 0.0 0.0
TRAN_MARK_SH 0.0 0.0 0.0
TRAN_MARK_UP 0.0 0.0 0.0
TRAN_MARK_EX 0.0 0.0 0.0
TRAN_MARK_DT 0.0 0.0 0.0
NETWORKIO 63075.0 22649.0 0.0
Total 2331864.0 2.4383404E+7 9738103.0

[Sergey Petrov_imported]

Цитата:

Сообщение от Vadik

показатели perfmon (процессор, очередь на диске, batch requests/sec) ?

<{POST_SNAPBACK}>

После очередной перезагрузки системе полегчало и средние значения параметров:
%Processor Time 28% (это идеальная ситуация, когда никто не висит - при зависаниях опубликую завтра, в среднем порядка 65-70%);
%Privileged Time 3% (в рабочем режиме порядка 25%);
Avg. Disk Queue Length (для диска с данными) 1.9
Batch Requests/sec 513

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

Постоянных дисковых очередей не наблюдается. Всплески тут же сменяются затишьем. В привилегированном режиме процессор работает мало, то есть на обработку I\O запросов уходит не так много времени. Основное процессорное время отжирает SQL Server (да кроме него и не запущено ничего).

Может, ещё какие счётчики посмотреть?

[Vadik]

Цитата:

Сообщение от Sergey Petrov

%Privileged Time 3% (в рабочем режиме порядка 25%);

<{POST_SNAPBACK}>

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

Цитата:

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

разве что
processor queue length
context switches/sec
network interface \ output queue length

ну и проверять клиентов на предмет KB814410 (та еще задача в условиях двухзвенки)

пока что вот так

[Sergey Petrov_imported]

Цитата:

Сообщение от Vadik

разве что
processor queue length
context switches/sec
network interface \ output queue length

<{POST_SNAPBACK}>

См. картинку.[attachment=285:attachment]

[Sergey Petrov_imported]

Цитата:

Сообщение от Vadik

показатели perfmon (процессор, очередь на диске, batch requests/sec) ?

<{POST_SNAPBACK}>

На картинках.[attachment=281:attachment][attachment=282:attachment][attachment=283:
attachment][attachment=284:attachment]