Еще раз про AOS и память

[Oleg V.Cat]

Все нижесказанное "имеет место быть" на 3.0 KR3. MSSQL.

Проблемы общего порядка в случаях, когда AOS хочет более одного гигабайта памяти - немного пообсуждали здесь: MaxMemPercentage - чегой-то я не понимаю

Теперь вопрос следующего порядка - а как заставить AOS отдать память? (либо - "как правильно пристрелить пользователя?") Разумеется, можно пристрелить сам AOS, но неприятно... В общем - картинки с выставки:

16:30 - AOS орет, "бла-бла-бла MaxMemPercentage"

поскольку до конца рабочего дня 30 минут во-первых, а во-вторых - поднята сессия с администратором - решаю не дергать рубильник, а разослав сообщение, что "у нас проблемы" - начинаю по одному отстреливать юзеров.

16:45 - осталось менее десятка юзеров. Раз в ~две минуты "бла-бла-бла MaxMemPercentage"

16:55 - два юзера, считая Админа. Картина прежняя. (Раз в ~две минуты "бла-бла-бла MaxMemPercentage")
Захожу на MSSQL, обнаруживаю гору висящих коннектов. Пристреливаю.

17:00 - закрываю собственную сессию. Через минуту обнаруживаю в эвент логе "бла-бла-бла MaxMemPercentage"

17:05 - дергаю рубильник... На момент дерганья - по прежнему сожрано порядка того самого гигабайта (нечто вроде 1080000КБ).

Так КАК?

[gl00mie]

Цитата:

Сообщение от Oleg V.Cat

Все нижесказанное "имеет место быть" на 3.0 KR3. MSSQL.
как заставить AOS отдать память? (либо - "как правильно пристрелить пользователя?")

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

Цитата:

Сообщение от Oleg V.Cat

16:55 - два юзера, считая Админа. Картина прежняя. (Раз в ~две минуты "бла-бла-бла MaxMemPercentage") Захожу на MSSQL, обнаруживаю гору висящих коннектов. Пристреливаю.
17:00 - закрываю собственную сессию. Через минуту обнаруживаю в эвент логе "бла-бла-бла MaxMemPercentage"

Для того, чтобы не гадать на кофейной гуще, придуман чудесный инструмент под названием Performance Monitor. Зарядите в нем нужные счетчики и отслеживайте, как, к примеру, изменяется счетчик Pool Paged Bytes для объекта Process, соответствующего вашему AOS'у, на фоне изменения счетчика Clients объекта Navision Axapta Object Server, соответствующего тому же AOS'у; посмотрите, как изменяются счетчики объекта Process при прибивании сессий на Ms SQL...

[Logger]

А еще есть вот это :
Мониторинг работы

Позволяет понять какой юзер сожрал процессорное время аоса. Это конечно не то что у вас, но тоже полезная штука.
Кроме того, часто так получается, что тот кто проц грузит на аосе - тот и память жрет.

А у вас похоже память течет на аосе. Плюс из описания неясно MSSQL установлен на том же сервере где аос или на другом ? Точно память АОС сожрал ?

[Oleg V.Cat]

Цитата:

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

А еще есть вот это :
Мониторинг работы

Спасибо, ссылки смотрю, думаю.

Цитата:

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

Позволяет понять какой юзер сожрал процессорное время аоса. Это конечно не то что у вас, но тоже полезная штука.
Кроме того, часто так получается, что тот кто проц грузит на аосе - тот и память жрет.

А у вас похоже память течет на аосе. Плюс из описания неясно MSSQL установлен на том же сервере где аос или на другом ? Точно память АОС сожрал ?

Ну процессор у нас, как правило, не загружен. Ни на AOS, ни на MSSQL. (стоит на разных серверах) . Судя по мониторингу - AOS грузит прощессор менее чем на 10% в среднем, вот SQL часто проседает, но тут уж сама Аксапта никаким боком, просто разработчики верят, что запросы можно писать левой ногой .

А в общем - похоже, что память действительно течет