SQL выжирает все процессорное время, как решить проблему - DAX: Администрирование

**sergeypp** · 22.03.2006, 12:10

На серваке (4 Xenon 2,4 Гб, 8Гб ОЗУ, Сиквелу выделено статически 6Гб.)
лежит база Axapta 30 Гб. 200 пользоваетелей в системе. Как понять в чем затык.. Либо код кривой, либо с серваком что-то не так.. Какими счетчиками и как можно определить в чем может быть дело. Система просто висит..

**Vadik** · 22.03.2006, 13:55

Цитата:

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

На серваке (4 Xenon 2,4 Гб, 8Гб ОЗУ, Сиквелу выделено статически 6Гб.)
лежит база Axapta 30 Гб. 200 пользоваетелей в системе

А кто Вам сайзинг системы делал? В принципе, из этих штанов (сервера) Вы либо уже выросли, либо это случится в самое ближайшее время. Тем не менее, чтобы перевести ветку в конструктивное русло:
- select @@version
- dbcc sqlperf(waitstats)
- perfmon по процессору и дискам (disk transfers/sec, average disk queue)
это для затравки

**sergeypp** · 22.03.2006, 16:22

Цитата:

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

- select @@version

Цитата:

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

- dbcc sqlperf(waitstats)

MISCELLANEOUS 1041.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 2286.0 2.7653155E+8 8850.0
LCK_M_U 4545.0 7.503088E+8 21065.0
LCK_M_X 1055.0 145098.0 2972.0
LCK_M_IS 2554.0 1.4965117E+8 6690.0
LCK_M_IU 18.0 45905.0 189.0
LCK_M_IX 1970.0 6576640.0 7154.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 434355.0 1.0797746E+8 1.0705312E+8
IO_COMPLETION 402440.0 1513840.0 10557.0
ASYNC_IO_COMPLETION 6.0 407.0 0.0
RESOURCE_SEMAPHORE 102.0 16284.0 547.0
DTC 0.0 0.0 0.0
OLEDB 633.0 6093.0 388179.0
FAILPOINT 0.0 0.0 0.0
RESOURCE_QUEUE 2501997.0 3.1917923E+8 1.0976838E+8
ASYNC_DISKPOOL_LOCK 68.0 0.0 0.0
UMS_THREAD 0.0 0.0 0.0
PIPELINE_INDEX_STAT 51.0 68938.0 66298.0
PIPELINE_LOG 0.0 0.0 0.0
PIPELINE_VLM 0.0 0.0 0.0
WRITELOG 1291828.0 9660308.0 2408510.0
PSS_CHILD 0.0 0.0 0.0
EXCHANGE 25083.0 95350.0 8576.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 323446.0 126134.0 117435.0
CXPACKET 1747199.0 2.8727779E+8 3401461.0
PAGESUPP 161337.0 489237.0 31173.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 8.0 16.0 16.0
LATCH_UP 737.0 3979684.0 1235.0
LATCH_EX 2.4667112E+7 5.0603392E+7 1.0521914E+7
LATCH_DT 0.0 0.0 0.0
PAGELATCH_NL 0.0 0.0 0.0
PAGELATCH_KP 141.0 109.0 109.0
PAGELATCH_SH 29443.0 111637.0 38758.0
PAGELATCH_UP 28371.0 232737.0 41049.0
PAGELATCH_EX 452773.0 718784.0 586266.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 8225469.0 6.0121584E+7 399283.0
PAGEIOLATCH_UP 1053.0 13902.0 157.0
PAGEIOLATCH_EX 448250.0 4389920.0 29984.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 127386.0 1005379.0 0.0
Total 4.0882756E+7 2.0308475E+9 2.3491994E+8

Цитата:

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

- perfmon по процессору и дискам (disk transfers/sec, average disk queue)

% загр проц - 97
Обращ к диску/сек - 450
Ср. длина очереди - 700

**Vadik** · 22.03.2006, 17:42

Цитата:

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

LCK_M_S 2286.0 2.7653155E+8 8850.0
LCK_M_U 4545.0 7.503088E+8 21065.0
LCK_M_IS 2554.0 1.4965117E+8 6690.0
..
SLEEP 434355.0 1.0797746E+8 1.0705312E+8
..
CXPACKET 1747199.0 2.8727779E+8 3401461.0
..
PAGEIOLATCH_SH 8225469.0 6.0121584E+7 399283.0
..
Total 4.0882756E+7 2.0308475E+9 2.3491994E+8

лочит систему неподетски

Цитата:

% загр проц - 97
Обращ к диску/сек - 450
Ср. длина очереди - 700

И вдобавок не тянет железо. Все плохо (это если вкратце)

**sergeypp** · 23.03.2006, 10:09

Цитата:

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

лочит систему неподетски

Нужно перестраивать индексы? или какие -то другие меры можно принять

Цитата:

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

И вдобавок не тянет железо. Все плохо (это если вкратце)

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

**Vadik** · 23.03.2006, 11:11

Цитата:

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

Нужно перестраивать индексы? или какие -то другие меры можно принять

Индексы перестроить конечно можно, но этого явно недостаточно. Надо долго и нудно мониторить приложение, анализировать модификации и т.д. и т.п.

Цитата:

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

учитывая, что

Цитата:

% загр проц - 97

- дисковая разгрузится, система в целом - маловероятно

Cheslav_imported · 23.03.2006, 11:36

попробуйте убрать автообновление и автосоздание статистики для БД (если оно установлено)
также можно временно попробовать остановить Agent

**sergeypp** · 23.03.2006, 14:58

База лежит на RAID5 если разбить базу на несколько лог. файлов, уменьшится ли загрузка винтов или для рейда это неэффективно?

Sergik · 23.03.2006, 18:03

Если на том же самом RAID, то бессмысленно. Будет эффект только при разнесении на несколько массивов. Но так как нагрузка на процах сервера БД 97 процентов, то эффекта реально не будет и в этом случае.

Кстати странно, что у вас такой высокий процент нагрузки на 4-х процессорах сервера БД. У вас трехуровневая конфигурация?

**sergeypp** · 23.03.2006, 18:06

да
5 терминалов, 4 аоса и около 200 пользователей

**Vadik** · 23.03.2006, 19:31

Цитата:

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

База лежит на RAID5

RAID5 - отказать, если только у вас не суперпупер контроллер с мегабатареей. Лог и tempdb уносить с этого массива куда угодно в любом случае

Цитата:

Кстати странно, что у вас такой высокий процент нагрузки на 4-х процессорах сервера БД

200 юзеров при

Цитата:

4 Xenon 2,4 Гб

, приложение по всей видимости без присмотра - нормально, по-моему

sp16RUS - начинайте например отсюда. И готовьтесь к тому, что война за производительность - это надолго

Sergik · 23.03.2006, 20:57

А что из себя представляют серверы приложений? Их загрузка на процессорах? Размер БД кстати какой (средний рост за месяц)?

Если процессоры серверов приложений в среднем загружены менее чем на 50%, а процессоры сервера БД реально загружены на 97 процентов (при 200 конкурентных пользователях и интенсивных операциях), скорее всего нужно его менять. Положительный эффект будет в любом случае, если к тому же по случаю разнести БД на дополнительные стойки с RAID10.

PS Работу по мониторингу приложения это конечно не отменяет.

**sergeypp** · 24.03.2006, 12:01

Загрузка на Аосах менее 30 % (проц)..
После того, как изменил некоторые параметры запуска, ситуация улучшилась.
% загр проца 80 - 85%
блокировок стало меньше
Но очередь на чтение под максимум
Еще один вопрос про счетчик Cahe Hit Ratio - в мануале говорится , что при низком значении малоэффективно используется ОЗУ и его нужно увеличивать, а низкое, это какое ??
у меня ср значение 90, но масштаб там 0,1 . вот и не пойму в чем они измеряют.

Sergik · 24.03.2006, 13:08

Можете не сомневаться, ОЗУ у вас используется очень "эффективно". Настолько эффективно, что наверняка происходит постоянная подкачка с дисковой подсистемы.

Размер БД какой?

Важно соотношение размер БД / объем RAM сервера БД. Если ниже 10 % то практически в любом случае у вас будет высокая очередь на дисках. На тех нескольких БД, которые я видел, оптимум ОЗУ >= 30% Это позволит снизить требования к дисковой подсистеме.

Кстати, режим AWE включен?

**sergeypp** · 24.03.2006, 17:38

AWE включен
ОЗУ 8 гигов
под SQL выделил статически 6 гиг
база 30Гб

Sergik · 24.03.2006, 17:57

Размер БД сравнительно небольшой. Обычно для 200 конкурентных пользователей поболее будет.
Кстати не пробовали запускать без AWE?

Может у вас большую долю активной нагрузки создает расчет аналитических отчетов?

В общем смотреть конечно нужно на систему своими глазами, удаленно трудно что-то посоветовать конкретное.

**sergeypp** · 25.03.2006, 10:02

Спасибо, буду пробовать

Еще один вопросик

Цитата:

Сообщение от serge kotov

Может у вас большую долю активной нагрузки создает расчет аналитических отчетов?

Ты имеещь в виду OLAP? или что?

у нас W2003 Ent Edition - если отключить AWE SQL не увидит больше 3 Гб памяти. В этом случае сервер же совсем помрет?

Sergik · 25.03.2006, 13:30

Нет конечно, сервер "совсем" не помрет. Дело в том, что AWE это только эмуляция расширенного адресного пространства, и как любая эмуляция, требует потребления ресурсов. Честно говоря не знаю как AWE реально повлияет на производительность в вашем случае. Процент нагрузки процессоров по идеи должен быть ниже при его отключении, но возрасти нагрузка на дисковую подсистему.

**sergeypp** · 27.03.2006, 17:54

Спасибо за совет, попробую отключить на субботу

**Vadik** · 27.03.2006, 18:35

Цитата:

Сообщение от serge kotov

Процент нагрузки процессоров по идеи должен быть ниже при его отключении, но возрасти нагрузка на дисковую подсистему.

Цитата:

Ср. длина очереди - 700

она (дисковая) уже лежит