29.10.2008, 13:08 | #1 |
Участник
|
Загрузка процессора на сервере БД
Добрый день!
Аксапта 3.0 СП4. В последнее время несколько раз в день процессор сервера БД внезапно загружается на 100%, ситуация "лечится" только включением\выключением АОСа. При этом в целом, нагрузка на систему небольшая, мало активных пользователей, нет блокировок и тд. Не подскажите как выявить причину\процесс\функционал (если проблема в функционале)? |
|
29.10.2008, 13:10 | #2 |
Участник
|
Может просто какой-то молодец отчетики строит напрямую на сервере? На СКЛ прямом?
Я помню у нас был один такой. |
|
29.10.2008, 13:20 | #3 |
Участник
|
Однозначно - нет. Все под контролем.
|
|
29.10.2008, 14:04 | #4 |
Участник
|
Сервер базы данных какой?
Надо смотреть, какая сессия нагружает, затем, что она делает. А дальше по ситуации.
__________________
Axapta v.3.0 sp5 kr2 |
|
30.10.2008, 10:28 | #5 |
Участник
|
Процессор грузит SQL 2000
|
|
30.10.2008, 10:53 | #6 |
Участник
|
Ну и?.. Как говорится, все телепаты сейчас в отпуске Трассировку запросов на нем включали, смотрели? Счетчики производительности его смотрели?.. Или вы ждете, что по описанным симптомам кто-то сейчас выдаст "гениальную догадку", точно описывающую причины тормозов в вашем конкретном случае?
|
|
30.10.2008, 11:13 | #7 |
Участник
|
Значит у вас SQL2000 постоянно занимается вычислением какой-нибудь функции.
Например, преобразованием кодовой страницы. Для начала проверьте, что в ODBC вы выключили галочку Perform translation of character data. http://axapta.mazzy.ru/lib/mssqlsetup/#090 Затем проверьте, что у вас установлена правильная кодовая страница. Не страница совместимости типа бла-бла-бла-Latin1-Win1251, а нормальная Cirilic_General_CI_AS после того, как разберетесь с кодовыми страницами ищите другие функции, которые должен выплонять процессор SQL'я. ======= А вообще говоря, позвали бы вы нормального спеца телепатия конечно "весч", но гораздо проще посмотреть в параметры. |
|
30.10.2008, 12:02 | #8 |
Участник
|
Есть такая утилитка - Qslice.exe. Ей можно посмотреть на АОСе какой юзер грузит АОС - думаю, что в этом случае и SQL. Ну и потом узнать - что юзер делает в этот момент.
|
|
30.10.2008, 12:04 | #9 |
Участник
|
mazzy: ODBC не используется в настройках (может быть стоит настроить?), кодовая страница стоит правильная.
egorych: Спасибо за совет, но АОС не грузится |
|
30.10.2008, 12:27 | #10 |
Участник
|
Посмотрите в Enterprise Manager какая сессия нагружает сервер.
Дальше, можно в профайлере посмотреть, что эта сессия делает на сервере, либо в Ax посмотреть в активных пользователях какой это пользователь и посмотреть что у него выполняется (если это Ax делает, кстати) Вот ссылка, где это можно найти
__________________
Axapta v.3.0 sp5 kr2 |
|
30.10.2008, 12:34 | #11 |
Участник
|
Конечно стоит. По-умолчанию галочка включена.
|
|
30.10.2008, 12:41 | #12 |
Участник
|
и еще. посмотрите план запроса.
есть ли там вычислимые функции? какие? |
|
30.10.2008, 13:18 | #13 |
Участник
|
В момент, когда процессор уходит в пике 100% нагрузки невозожно ничего делать: невозможно удаленно подключиться к серверу, невозможно открыть enterprise manager, все мертво...это создает проблему диагностики...
|
|
30.10.2008, 13:23 | #14 |
Участник
|
Хм. А как вы тогда пришли к выводу, что загружает SQL?
__________________
Axapta v.3.0 sp5 kr2 |
|
30.10.2008, 17:53 | #15 |
Участник
|
Подконнектились к серверу, открыли диспетчер задачи и ждали...
|
|
30.10.2008, 18:16 | #16 |
Участник
|
запустите локально на сервере БД Performance Monitor, собирайте данные по счетчикам загрузки ЦП в целом по системе и по процессу SQL Server, поставьте соответствующему процессу mmc.exe высокий приоритет, чтобы он не затыкался, когда кто-то другой будет сильно грузить ЦП. так данные будут и более объективные, и сохраненные для последующего анализа, в отличие от графика, который рисует Task Manager
|
|
31.10.2008, 10:42 | #17 |
Участник
|
После настройки подключения АОС-а к базе через ODBC наблюдаем в логе трассирофки запросов в Аксапте следующе:
[Microsoft Business Solutions-Axapta] Unable to retrieve message for retval -1, ODBC call reason code 100, SQLSTATE = [GNJ] Error message [] |
|
31.10.2008, 10:57 | #18 |
Участник
|
Цитата:
помните одно - барабашки нет! |
|
31.10.2008, 23:23 | #19 |
Участник
|
1. Вы уверены, что на сервере загрузку ЦП дает именно SQL ? Это могут быть и результаты работы например "ГиперВирусов" (почему-то их еще называют антивирусами). В этом может помочь Perfomance Monitor или Task Manager.
2. При загрузке SQL под 100%, когда Enterprise Manager не отвечает, можно попробовать найти "гадкий" процесс через Query Analyser с помощью системных ХП sp_who & sp_who2. В большинстве подобных "клинических" случаях это помогает получить информацию о spid, который грузит проц. Далее по spid из Аксапты можно попытаться узнать юзера, его породившего. Ну, а на сладкое: "допрос юзверга с пристрастием". 3. Как уже выше советовали, т.к. ситуация достаточно воспроизводимая, то запускаете с утреца Profiler, с событиями не только *Complited, но и *Started. В момент "кризиса", сбрасываете получившиеся данные в отдельную БД на другом сервере, перегружаете АОС и далее спокойно анализируете последние запросы в Query Analyser. Только не накладывайте в настройке фильтров на загрузку ЦП !!! PS. Барабашки есть всегда и везде, просто обычно они умеют хорошо прятаться |
|
Теги |
aos, документация, производительность, ax3.0 |
|
Похожие темы | ||||
Тема | Ответов | |||
Подключение АОС к новой БД | 4 | |||
Владельцы таблиц в БД аксапты | 11 | |||
Резко подскочила загрузка процессора | 20 | |||
2 AOS + 2 БД = 1 сервер | 2 | |||
Создание точной копии БД для анализа ошибок | 1 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|