Резко подскочила загрузка процессора

[sergeypp]

Господа.. подскажите.. в чем может быть дело..
Второй день как подскачила загрзузка проца.. среднее значение 99.2
Вчерашний день объяснить могу.. ночью не отработались пакеты и их запускали днем..
сегодня та же история.. думал может сам сиквел глючит.. перезагрузил сервер
как только кол-во подключений перевалило 100 загрузка подскачила под 100 процентов и там остается...
пакетный сервер остановлен.. дисковых очередей нет.. посмотрел самые жрущие проц процессы - почти все выполняют команду sp_cursorprepexec;1
никаких изменений в настройках не делал.. дополнительных функционалов вроде не запускалось..
как определить что привело к такой загрузке пока не понял.. посоветуйте куда копнуть...
заранее спасибо

А SQL 2005?

[sergeypp]

я же его прямо сейчас не воткну?? переход тестируется..
проблема в том что пару дней назад все было приемлимо.. а сейчас - тихий ужас.. что то же повлияло.. а что я пока не понял

[KiselevSA]

А sp_who2 что показывает? Найти процесс с большими временами для процессора и дисковым вводом-выводом. Дальше анализировать профайлером. Или загрузка относилась к AOSу?

[sergeypp]

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

[sergeypp]

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

[KiselevSA]

Цитата:

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

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

А Вы разработайте свою таблицу, в которой складдируйте время начала и завершения запроса. В анализируемых операциях добавьте обрамление: начало операции, окончание операции. При наличии отметки в настройке регистрации времени по запросу, пишите в таблицу. Дальше анализируйте

[raz]

Как обнаружить какой пользователь загружает процессор AOS

[sergeypp]

2 KiselevSA.. уже придумываю.. пишу тз..
2 raz.. спасибо.. это я видел.. аосы у меня не грузятся.. грузится сервак с базой.. сегодня ситуация не лучше.. разбираюсь

[Maxim Gorbunov]

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

[sergeypp]

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

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

[Maxim Gorbunov]

То есть Ваша новая супер-мега-функция, "складдирующая время начала и окончания запроса", систему не добьет, а стандартный аксаптовский мониторинг длинных запросов, который делает то же самое - наоборот. И в чем же принципиальное отличие новой функции от старой?

[sergeypp]

Новая функция еще не работает.. и так все плохо..
и к тому же она не будет собирать информацию по скулевым запросам.. она должна будет собирать информацию какой пользователь какую кнопку нажал в системе.. это довольно просто и не ресурсоемко..
а вот трассировка, поставленная на 10 человек.. действительно подвесит систему..
и опять таки.. что я увижу?? какие запросы обрабатыватся.. мне же нужно узнать.. почему эти же запросы неделю назад не тормозили систему..
хватает того что я профайлером чучаю сервер.. профайлер ничего необычного не показывает

[sergeypp]

вот пример трассы..

[Maxim Gorbunov]

Да Вы хоть попробуйте перед тем как ТЗ писать. Трассировка в Аксапте Вам не только запрос и его план сохранит, но и стек вызовов X++, в котором, как раз, и будет видно, какая кнопка была нажата.

Между прочим, даже по Вашей трассе некоторые выводы уже можно сделать. 20% загрузки процессора идет от клиента olap-terminal. Примерно 60% приходит от aos2-client и aos3-client. Посмотрев на их запросы, можно заметить, что за 5 минут, что работал профайлер, всего было 7 запросов, занимавших процессор дольше 10 секунд. 6 из них - запросы к INVENTSUM (подозреваю, что и 7ой тоже, но наверняка сказать нельзя, так как это sp_cursorfetch, а курсор был подготовлен, видимо, раньше, чем началась трассировка). Вот с ней и надо разбираться.

[sergeypp]

Трассу я снимал с условием cpu > 100.. ПО поводу INVENTSUM - еще раз проверю актуальность индексов.. спасибо за замечание
Проблему я частично решил.. Обнаружил, что на аосах слетели настройки по литералам.. с чем связано не понял... перезгрузил аосы.. поставил предварительную компиляцию.. сейчас загрузка около 80 % возможно было из-за этого.. а может и нет.. на 100% не уверен..

[Maxim Gorbunov]

Цитата:

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

Обнаружил, что на аосах слетели настройки по литералам..

А какие конкретно у Вас настройки стоят? Подозреваю, что были включены. А сейчас? Просто любопытно.

[sergeypp]

галки с litetals я снимал собственоручно.. а сегодня обнаружил, что они снова там стоят.. после того как я их снял - ситуация улучшилась

[sergeypp]

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

[Maxim Gorbunov]

Ага, понятно. В принципе, логично: запросы к INVENTSUM по структуре одинаковые, соответственно, если с placeholders их делать, перекомпилироваться они не будут, следовательно процессорное время сэкономится. Кстати, можно еще попробовать с Hint flags поиграть, так как не факт, что индекс ClosedItemDimIdx в Вашем случае оптимальный.

Вообще, рекомендую статьи Вадима Гончаренко к обязательному прочтению:
Literals vs placeholders
Index hints и MSSQL
Оптимизация запросов