Регулярное падение AOS-в в AX3.0

[titov]

В вашей архитектуре есть "толстые клиенты"? Если да проверьте, откуда они берут приложение.
И еще вариант - почистите локальные кэши клиентов аксапты. Хорошо бы "поймать" последнего пользователя, который не смог зайти в систему и посмотреть eventLog на его компьютере (это если принять гипотезу, что источник падений - клиент).

[snirk]

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

Цитата:

"Хорошо бы "поймать" последнего пользователя"

Еще бы! Сейчас думаем, как это сделать...

[titov]

Цитата:

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

Еще бы! Сейчас думаем, как это сделать...

Как вариант - профайлер SQL - поставить фильтр RPC,DataBaseName = ваша база, ObjectName = CREATEUSERSESSIONS. Сессия клиента у вас создается, в этой точке выполняется хранимая процедура CREATEUSERSESSIONS, а далее смотрим время и пользователя. Может так что-то "поймаете".

А что показывают "Журналы SQL Server"?
Проверьте порты АОС - маловероятно, но все же. В трешке был режим запуска АОС по вызову - вот в этом случае может "неожиданно" вклинится АОС с совпадающим портом.
И еще момент - в какой-то трешке была сильная утечка памяти на АОС - поставьте счетчики, чтобы проверить.

[S.Kuskov]

Цитата:

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

Запрос странен не только количеством, но и формой. Включал трассировку всех запросов в момент запуска приложения - от момента запуска, до открытия одной из форм... Обращения к UserInfo есть, но ни в одном из них нет оператора IN с перечислением констант, только WHERE (ID=?).
Программист я, последние пару лет ничего связанного с UserInfo не писалось. StartupPost чист в этом отношении. По всему коду конечно поищу, но если что и писалось, то в формулировке WHERE id=id, а это так и передается в SQL, а не IN.

Извините если не в тему, тут просто в соседней ветке как раз запостили пример такого запроса к UserInfo Настройка прав доступа на просмотр всех Пользователей. Ax 2009 может это никак и не поможет, но всё же

[snirk]

АОСы упали опять, на этот раз примерно в 8:20, оба...

Что делалось (соответственно не помогло):
Синхронизация DataDictionary по совету Poleax. Ошибку нашли, исправили, добились синхронизации без ошибок.
Повторная глобальная перекомпиляция

Исследования:
Был изменен SysUserLog по совету gl00mie, версия клиентов все равно одна и та же у всех.
Мониторинг пользователей (последние которые подключались до падения, первые которые подключались после падения) - отследить их можно в EventLog-ах на АОСах. Проверили каждый комп - в логах есть только пару warnings связанных с политиками безопасности.

Замечено:
Создали 3-й АОС, подключили его в кластер, но не пускали на него пользователей (только пакетные задания). Так вот, он не упал.

Догадки заканчиваются. Сегодня начисто пересоздадим первые 2 АОСа.

[gl00mie]

А в настройках соединения с БД (вкладка Database, группа Connection) что у вас прописано касаемо неактивных соединений? Они закрываются по таймауту или продолжают висеть? Был как-то косяк с АОСами 3.0, правда, на Оракле: в настройках был выставлен определенный таймаут, по истечении которого АОС пытался закрывать неактивные соединения с СУБД, правда, делал это как-то криво, и на СУБД сессии в результате оставались висеть. Это приводило к тому, что, во-первых, отжиралась лишняя память на СУБД, а во-вторых, в определенный момент при создании новых соединений тупо заканчивались TCP-порты, и АОС падал. Если у вас настроено завершение неактивных соединений с СУБД по таймауту, попробуйте перенастроить АОСы так, чтобы они их не завершали, а оставляли висеть.

[Perc]

"internal revision mismatch.." если вы про эту ошибку. В какой то момент новых пользователй не пускает.
Проблема эта у нас уже много лет.
AX3.0 SP4. СУБД - было и MS SQL Server2000 и сейчас 2005
версии приложений и клиентов у нас не меняются с 2006г.
На одну базу и приложение 1 аос. Пользователей активных редко бывает больше 80. Все работают через 1 аос.
Когда то админ наш давно пытался искать, спрашивать. Темы на этом форме были уже. Но успехом не увенчалось, смены параметров, серверов, АОСа.
В общем смиренно мучаемся.
В период особой активности пользователей (конец,начало месяца) перезапускаем по несколько раз на дню АОС. В другие периоды может неделю стоять АОС без перезапуска.
В последнее время стало особо досаждать тем что появилась необходимость к томуже перестартовать пакетный сервер.
В общем я решил для себя что это проблема АОСа по работе с памятью. Причем если АОС не перестартовать, забить на новых пользователей, мол пускай существующие работают, то всеравно очень скоро проявляется неадекватная работа, зависания.. ну и итог рестарт.

Было б очень клево если б вы нашли корень зла)

[gl00mie]

Не знаю, как AOS, а клиент AX 3.0 SP4 славился просто дикими утечками памяти. По-моему, если уж и работать на трешке, то лучше взять последнее официально выпущенное ядро - KR3.