счетчик производительности SQL cursors active

[SHiSHok]

ax3sp3, интересует как ведет себя у кого счетчик производительности SQL connections active (описание Number of currently active SQL connections). У меня он почему-то перманентно растет. Отсюда вывод: либо утечка коннектов, либо счетчик глючит. Есть подозрение что глючит, потому что в настройках АОС стоит настройка Max. Open Cursors и она уже в несколько раз превышена.

[egorych]

Курсоры и коннекты - несколько разные вещи и между собой почти несвязаны!
Веб пользователи есть?

[SHiSHok]

Цитата:

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

Курсоры и коннекты - несколько разные вещи и между собой почти несвязаны!
Веб пользователи есть?

Ёлки-иголки, действительно , совсем запарился.
Речь именно о курсорах! Обьект Navision Axapta Object Server, счетчик SQL cursors - active описание: Number of SQL cursors currently active.
Web юзеров нет.

ЗЫ: как бы заголовок темы поправить

[fed]

Настройка Max Open Cursors относится не ко всему AOS в целом, а к сессии. Фактически - это количество закэшированных запросов, которые Аксапта пытается реюзать в рамках сесии. При закрытии сессии, закэшированные курсоры теоретически должны быть закрыты. Но: Если вы поставили параметр session timeout (или как он там называется. В 2009 этот параметр отсутствует, а более старых версий системы под рукой нет чтобы посмотреть) в конфигурации сервера приложений (в control panel которая), то при выходе пользователя из системы, сессия на самом деле не закрывается, а тоже некоторое время хранится в кэше с целью повторного использования. Кстати - если этот параметр не трогать, то сессия тоже кэшируется. Кажется секунд 15 для сиквела и 2 минуты для оракла.
Так что в пределе, число закэшированных курсоров должно равняться среднему числу сессий, помноженному на максимальное число открытых курсоров.

[SHiSHok]

Цитата:

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

Настройка Max Open Cursors относится не ко всему AOS в целом, а к сессии. Фактически - это количество закэшированных запросов, которые Аксапта пытается реюзать в рамках сесии. При закрытии сессии, закэшированные курсоры теоретически должны быть закрыты. Но: Если вы поставили параметр session timeout (или как он там называется. В 2009 этот параметр отсутствует, а более старых версий системы под рукой нет чтобы посмотреть) в конфигурации сервера приложений (в control panel которая), то при выходе пользователя из системы, сессия на самом деле не закрывается, а тоже некоторое время хранится в кэше с целью повторного использования. Кстати - если этот параметр не трогать, то сессия тоже кэшируется. Кажется секунд 15 для сиквела и 2 минуты для оракла.
Так что в пределе, число закэшированных курсоров должно равняться среднему числу сессий, помноженному на максимальное число открытых курсоров.

в 3-ке настраивается time-out для connection, у меня настроен 30 мин, НО, часть сотрудников работает 8 часов в день, соответственно когда они уходят домой то все тайм ауты истекают, а значение счетчика SQL cursors не уменьшается.

[sukhanchik]

Цитата:

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

ЗЫ: как бы заголовок темы поправить

Поправлено

[fed]

Цитата:

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

в 3-ке настраивается time-out для connection, у меня настроен 30 мин, НО, часть сотрудников работает 8 часов в день, соответственно когда они уходят домой то все тайм ауты истекают, а значение счетчика SQL cursors не уменьшается.

Гм. Единственное что могу предположить - что это тупой глюк монитора
А в чем собственно первоначальная проблема ? Почему вопрос возник ?

[SHiSHok]

Цитата:

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

Гм. Единственное что могу предположить - что это тупой глюк монитора
А в чем собственно первоначальная проблема ? Почему вопрос возник ?

падения АОС. мер принял множество, мониторинг курсоров - один из подозрительных моментов утечки ресурсов.

Интересно как в других системах 3-й версии (желательно sp3cu1) этот счетчик ведет себя. Когда АОС без пользователей этот счетчик должен быть = 0. На тестовой у меня все красиво (но там 2-3 человека живет и не сильно напрягают ф-ционал), а вот на основной счетчик растет и при выходе всех юзеров уже не 0.

[fed]

Ну я бы тогда заодно и SQL Connections помониторил бы. Если их количество по ночам не падает - то проблема не в курсорах, а в соединениях. Да и кстати я не вижу смысла ставить таймаут по соединению в 30 минут. Это на оракле соединения долго устанавливаются (типа секунду-две), а в сиквеле - можно было бы смело этот таймаут либо не трогать либо поставить туда секунд 30...

[SHiSHok]

Цитата:

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

Ну я бы тогда заодно и SQL Connections помониторил бы. Если их количество по ночам не падает - то проблема не в курсорах, а в соединениях. Да и кстати я не вижу смысла ставить таймаут по соединению в 30 минут. Это на оракле соединения долго устанавливаются (типа секунду-две), а в сиквеле - можно было бы смело этот таймаут либо не трогать либо поставить туда секунд 30...

коннекты адекватно себя ведут - где-то порядка как и Clients,а вот курсоры...
насчет таймаута возможно вы правы, можно попробовать сделать по дефолту, но мне кажется что не сильно изменит картину. На тестовой наблюдал как SQL cursors - active себя ведут: после закрытия формы, отработки кода в течении 5-7 сек счетчик активных курсоров уменьшается в исходное состояние (это с моими таймаутами)

[somebody]

Цитата:

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

Обьект Navision Axapta Object Server, счетчик SQL cursors - active

Вы бы помониторили курсорные счётчики в Performance на SQL-сервере, для 2005-го это "SQLServer:Cursor Manager by Type/Active cursors", для API Cursor.
Т. е. реально есть ли эти курсоры на SQL, или это какая-то утечка/фантомы/глюки мониторинга именно на АОСе.

Цитата:

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

Курсоры и коннекты - несколько разные вещи и между собой почти не связаны!

Что касается сиквела, то server-side-курсор требует открытого соединения, клиентский - не требует...

P. S. Число соединений-то не растёт... Но это соединения с АОСом. А что с сиквелом? Ну, правда, надо смотреть, есть ли ещё 2-хзвенные...

[SHiSHok]

Цитата:

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

Вы бы помониторили курсорные счётчики в Performance на SQL-сервере, для 2005-го это "SQLServer:Cursor Manager by Type/Active cursors", для API Cursor.
Т. е. реально есть ли эти курсоры на SQL, или это какая-то утечка/фантомы/глюки мониторинга именно на АОСе.

в 2000 этого нет.

[SHiSHok]

Интересное поведение счетчика SQL cursors - active: после старта АОС некоторое время отображает вроде как адекватное кол-во курсоров т.е. Active = Cached - Total.
"SQL cursors - total" = Total number of open SQL cursors (active and cached).
В один прекрасный момент значение Active инвертируется (например FFFFFFF4h) и дальше отображается в таком виде. курсоры потихоньку растут (значение уменьшается, т.к. инверсия) пока АОС не слетит.

может кто знает где копать?

[Owl83]

Всем доброго времени суток

Хотелось бы возродить этот заброшенный тред.

Имеем в компании аналогичную проблему. Если аосы работают без перезапуска более 5-7 дней, то наблюдаются падения аосов либо аномальные тормоза.

Имеем два аоса, находящиеся на отдельных машинах. Аосы объединены в кластер.
Чтобы было, о чем подумать, настроил мониторинг счетчиков Navision Axapta Object Server.

Выяснилась такая картина:
1. на первом аосе значение счетчика SQL cursors - active колеблется в районе 450-600, а на втором стабильно растет, примерно по 400-500 в день.
2. последний случай тормозов (множественные блокировки друг друга среди пользователей, повышенная нагрузка на сервер MSSQL) совпал по времени с тем, что на втором аосе значение этого счетчика доросло примерно до 4500 и стабилизировалось на этой отметке на несколько часов, пока вечером аосы не перезапустили.

Из того, что уже обсуждалось выше по нашей ситуации могу сказать следующее:
* Параметры Max Open Cursors и session timeout в настройках аосов у нас не указаны.

* Значение счетчика SQL connections - active меняется в зависимости от количества клиентов. При уменьшении SQL connections - active уменьшения SQL cursors - active не происходит.

* На сервере MSSQL значение счетчика SQLServer:Cursor Manager by Type/Active cursors ведет себя вполне нормально и после окончания рабочего дня снижается почти до нуля.

Хотелось бы узнать, как эта проблема решилась у автора топика.
И кто что может посоветовать в такой ситуации.

[Maximin]

Я бы начал с проверки совпадения версий .exe АОСов и глобальной компиляции приложения в подходящем по версии клиенте. Ну и установке заодно как минимум SP3 на SQL 2005, будет такая версия используется, а лучше - SP4 c Cumulative updates.

[SHiSHok]

Цитата:

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

Имеем в компании аналогичную проблему. Если аосы работают без перезапуска более 5-7 дней, то наблюдаются падения аосов либо аномальные тормоза.
Хотелось бы узнать, как эта проблема решилась у автора топика.

отрефакторил кучу куда - не помогло, в итоге разнес юзверей на 2 аоса. сейчас более менее нормально.
Если у Вас 5 дней нормально пашет, введите штатную процедуру перезагрузки АОСов на выходных. Я, например, на выходных заливаю проекты + перегружаю Ax.

PS. версия Ax и сиквела какая?

[Owl83]

SQL active cursors по всей видимости к нашей ситуации не имеет отношения.

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

Расход памяти на старых аосах, где сидят одни обычные пользователи, стабилизировался, а на новом наблюдается стабильный рост. Особенно в ночное время, когда выполняются самые тяжелые обработки