Странности в поведении Axapt'ы - DAX: Администрирование

Sergey Petrov_imported · 27.09.2005, 11:14

Доброе всем время суток!
Начну с описания системы.
Используется Axapta 3.0 CIS SP3 c 2-хзвенной архитектурой. Логика хранится на файл-сервере. Сервер базы данных на платформе Intel SPSH4, 4 процессора Xeon MP 2200 2Gb L3 Cache (без включённого Hyper Threading) с 400 MHz системной шиной. Оперативной памяти 12 Gb. Операционная система Windows 2003 SP1. Севрер базы данных MS SQL Server 2000 с фиксированым объёмом оперативной памяти (11 Gb). Для хранения данных используется дисковый массив RAID-0 из 5 дисков. Логи хранятся на отдельном дисковом массиве RAID-0 из 3 дисков. Операционная система хранится отдельно от программного обеспечения SQL Server. Сервер подключён к гигабитному свитчу, к которому подключены также и 100-мегабитные cвитчи пользователей.
Одновременно с системой работают около 70 пользователей. Область применения: книготорговля (склады, магазины, отдел закупок).
Проблема: повышение загрузки процессоров (больше 80%) при большом количестве пользователей (особенно заметно при объёмных операциях отдела закупок). При этом наблюдается замедление работы пользовательских приложений вплоть до полного их "зависания".
Странности в поведении: после перезагрузки сервера у пользователей проблем практически нет в течение где-то полу-дня. Потом всё становится "на свои места".
Вопрос: как можно повысить производительность сервера базы данных (и, тем самым, всей системы) и объяснить такое "странное" поведение приложения?
P.S. Я - системный администратор и в тонкостях Axapt'ы разбираюсь не очень хорошо. Поэтому возможны "глупые вопросы".

**mazzy** · 27.09.2005, 11:19

Для начала - универсальный совет

Аксапта падает. Что делать?

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

И еще. Большое количество пользователей для вас - это сколько?
Сколько пользователей в среднем одновременно работает в вашей Аксапте?

Sergey Petrov_imported · 27.09.2005, 12:32

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

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

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

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

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

**mazzy** · 27.09.2005, 12:38

Цитата:

Сообщение от 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/
и далее по ссылкам.

**Vadik** · 27.09.2005, 16:43

Цитата:

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

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

<{POST_SNAPBACK}>

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

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

Цитата:

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

Ужас..

Sergey Petrov_imported · 27.09.2005, 19:21

Цитата:

Сообщение от 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 у нас не используется.

Sergey Petrov_imported · 27.09.2005, 19:31

Цитата:

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

select @@version ?

<{POST_SNAPBACK}>

Цитата:

Сообщение от 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 · 27.09.2005, 20:16

Цитата:

Сообщение от 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** · 27.09.2005, 20:53

Цитата:

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

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

<{POST_SNAPBACK}>

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

Цитата:

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

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

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

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

Sergey Petrov_imported · 27.09.2005, 21:57

Завтра смогу предоставить более точную информацию (сбор данных уже включил по указанным Вами счётчикам). Насчёт KB814410 - там написано, что применимо к SP3, а у нас SP1. Он тоже болеет?

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

**mazzy** · 27.09.2005, 22:56

Цитата:

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

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

<{POST_SNAPBACK}>

Цитата:

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

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

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

**Vadik** · 27.09.2005, 23:17

Цитата:

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

Насчёт KB814410 - там написано, что применимо к SP3, а у нас SP1. Он тоже болеет?

<{POST_SNAPBACK}>

если Вы не пошутили с

Цитата:

Microsoft SQL Server 2000 - 8.00.760

, у Вас все-таки SP3 или SP3a (см. How to determine which version of SQL Server 2000 is running)

Sergey Petrov_imported · 28.09.2005, 12:24

Как выяснилось, мы используем более новую версию MDAC (при инсталляции клиентской части аксапты мы обновляли ODBC драйвера, используя MDAC версии 28.0.1022.3, а указанный MDAC 2.7 SP1 имеет версию 27.1.9040.2). Сейчас хочу скачать MDAC 2.8 SP1. Так что, к сожалению, проблема не в этом.

Sergey Petrov_imported · 30.09.2005, 13:14

Цитата:

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

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

<{POST_SNAPBACK}>

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

Sergey Petrov_imported · 30.09.2005, 13:29

Цитата:

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

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

<{POST_SNAPBACK}>

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

**Vadik** · 30.09.2005, 20:16

Да, достаточно активные они, Ваши 80 клиентов

Хотя я ожидал чего-то похуже

InventSettlement не трогайте, по крайней мере пока

В сторону от производительности - до сих пор вздрагиваю, когда вижу в Вашей ветке на sql.ru упоминания о RAID0 и simple recovery model. За низкую производительность Вас конечно не похвалят, а вот за потерю данных - расстреляют обязательно

Где-то у меня валялся забавный документ, где рассчитывалась вероятность выхода из строя для разного уровня массивов RAID в течение года в зависимости от количества дисков в массиве. Надо или его найти, или вспомнить вузовский курс теории вероятностей

Sergey Petrov_imported · 30.09.2005, 20:34

Цитата:

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

Да, достаточно активные они, Ваши 80 клиентов

Хотя я ожидал чего-то похуже

Чего уж хуже! Нам бы их усмирить...

Цитата:

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

InventSettlement не трогайте, по крайней мере пока

Да мы пока и не трогаем ничего. Собираем информацию, что можно потрогать.

Цитата:

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

В сторону от производительности - до сих пор вздрагиваю, когда вижу в Вашей ветке на sql.ru упоминания о RAID0 и simple recovery model. За низкую производительность Вас конечно не похвалят, а вот за потерю данных - расстреляют обязательно

Где-то у меня валялся забавный документ, где рассчитывалась вероятность выхода из строя для разного уровня массивов RAID в течение года в зависимости от количества дисков в массиве. Надо или его найти, или вспомнить вузовский курс теории вероятностей

<{POST_SNAPBACK}>

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

Хотя, можно было сделать 2 RAID10 (правда, на 2-х дисках). Но... Вот коли соберётесь к нам в гости - думаю, всё и поднастроим.

А для бэкапов у нас простого стиммера и то нет. Зато 4 процессора!

))