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

[db]

сессии с номерами подобными 65535 это рабочие потоки (WorkerThread). В стандартной 3.0. есть вроде только одно место где они используются - класс SysEventHandler. Главная задача этого класса - сбрасывать различные кеши если используется несколько аосов. Возможно в вашем случае это при большом количестве активных юзеров приводит к завалу аоса, а в выходные когда юзеров мало, то не приводит. Можно попробовать на пару дней отключить этот фунционал, подправив метод shouldRun и посмотреть что будет. Заливать модификации на ходу и править данные в сильно кешированных таблицах в это время не стоит

все вышесказанное на правах пространных размышлений

[snirk]

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

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

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

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

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