AX 2012 - глюки ядра

[SRF]

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

Удалось обнаружить вот такую зависимость :

Если операция работала относительно долго (например, больше пары часов, хотя обычное время работы в среднем 20-30 минут), то через определенный промежуток времени скорость обработки документов существенно падала в сравнении с тем, что было с начала процедуры.

Снимали трассировку и там примерно такие же проблемы - queryValue, табличный кеш, с парсингом xml какие-то затыки возникали(был еще запрос в коробке, который тоже на длительных операциях проявляется, но он легко оптимизируется).

При этом я смотрел потребление памяти службой АОСа - после запуска потребление памяти резко росло (в течении пары минут съедалось несколько гигабайт), но даже если ПО работала существенно дольше, например, 12 часов то как правило объем памяти не превышал 18-20 ГБ (точных цифр не вспомню, но мне кажется больше 20ки я не видел).

В целом есть ли связь именно с объемом потребляемой памяти - типа условно, после XXX гб АОС начинает тупить, не знаю, не уверен, у меня скорее гипотеза в том, что когда порог неутилизированной памяти(т.е. та, которую можно было бы уже освободить) превышает определенный порог, то у АОСа начинаются проблемы.

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

В целом вот еще интересная статья по теме памяти (думаю видели, но на всякий случай оставлю ссылку тут) - https://cloudblogs.microsoft.com/dyn...in-xppil-code/

Хоть к теме и не относится, я вот пока ни на одном проекте еще не видел, чтобы где в то кастомизациях query\queryrun finalize вызывался.

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