DAX2009 забирает всю память

[Ivanhoe]

Дождитесь пока упадет AOS, в чем проблема? Даже очень вредные пользователи и крутые компании могут понять необходимость однократного падения во время работы.

[FrolovAndy]

Попробую сразу в одном сообщении ответить на всё.

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

Пытаться перекидывать на другой АОС будет проблематично. У нас специфика, использование Workflow стандартного, и для него важно чтоб на машине где крутится АОС, была обеспечена вся необходимая инфраструктура. Выделять ещё один АОС - это означает проделывать ещё раз все действия для обеспечения работы Workflow, и поэтому у нас на такой шаг пойдут в последнюю очередь. Собственно, из-за этого даже пакетные обработки по WF крутятся на основном АОСе, по этой же причине что на пакетном сервере не хотят устанавливать WF. Иначе было бы здорово, как раз по одному переводить на пакетный АОС и наблюдать за изменениями в памяти, но никак.

По функционалу тоже особо не определишь, в основном используется свой модуль написанный сбоку. В той или иной степени все принимают в нем участие. Отловить по отдельным действиям пока не получается.

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

С другой стороны, когда я смотрю на то что происходит в рабочей среде, там нет каких-то мощных темпов расходования памяти, она просто плавно уходит, и не возвращается
И вот я попробовал поэкспериментировать на тестовом, уже не запуском замысловатых алгоритмов, а просто как пользователь - открываю-закрываю формы, какие-то отчеты запускаю, действия выполняю... И вот что интересно - именно при такой работе у меня тоже пошла уходить память понемногу, но безвозвратно. Не скажу что большой расход, но я по себе прикинул что если помножить это на количество пользователей и на количество рабочих часов, то в сумме как раз и будет та самая утечка
То есть что-то происходит на обычном уровне использования системы такое, что уводит память безвозвратно. Не какой-то глючный алгоритм в отдельно взятом месте, а просто обычный рабочий процесс. Это больше наталкивает на мысль о глюке в интерфейсной части.
Ведь опять-таки - отдельно выделенный пакетный АОС утечек не создает. В то время как на нем много чего крутится, различного функционала. Казалось бы там еще больше должно расходоваться. А дело видимо в тех процессах которые отвечают конкретно за уровень взаимодействия с пользователем. Может и обновить что-то надо, а может где-то некорректно допилили какую-то общеиспользуемую штуковину типа SysSetupFormRun или что-то около того где интерфейс обеспечивается, в общем других вариантов пока для себя не вижу кроме как зайти теперь с этой стороны

P.S. SysHeapLog не помог каким-то ощутимым образом. Может у него где-то есть какие-то особенные возможности о которых я не знаю, но то что удалось вытащить с его помощью это общая информация с помощью которой всё равно непонятно где копать. Либо я плохо с ним разобрался

[Ivanhoe]

У вас точно актуальная версия kernel? Если течет прям ядро, то тут сами ничего не решите.

А насчет дампа, мне три раза находили с помощью его утечки, не думаю, что мне так везло что падало именно на коварном коде

[FrolovAndy]

Я тут похоже наврал со своими наблюдениями. Да, по чуть-чуть память отбирается, но основные утечки - это прямо скачки когда за 10-20 секунд улетает до 100 Мб
Стал всячески копать, и докопался вот до чего, это 99,9% момент ухода памяти - выполнение пакета обработки событий стандартного Workflow.
Всё на нем сходится. Даже при низкой активности пользователей, когда одновременно два-три человека сидят, и память никуда не уходит, но как только появляется подходящая для обработки запись в WorkflowMessageTable, то всё, можно делать ставки сколько мегабайт отожрется в момент очередного запуска пакета
Мешает на все сто процентов поверить в это только одно - сам пакет отрабатывает через каждую минуту +/-, из-за этого в голову периодически приходит мысль "а вдруг простое совпадение"
Но! Ни разу при мне память скачками не убегала вне периода выполнения пакета, и ещё точнее - этого ни разу не происходило при "холостом" выполнении пакета (т.е. когда ни одного события по факту нет). Да, бывало обратное - есть события, но память не расходуется. Ну, это наверно больше говорит о том что разные события вызывают разный код, и не факт что прямо на любом варианте обязаны быть утечки

Ну хотя бы теперь уже есть понимание где воспроизводить и искать концы.
Если кто что-то слышал про утечки от Воркфлоу, поделитесь опытом пожалуйста. Я правда грешу всё таки на нашу собственную специфику разработок, но тут любая инфа полезной будет.

Цитата:

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

У вас точно актуальная версия kernel? Если течет прям ядро, то тут сами ничего не решите.

А насчет дампа, мне три раза находили с помощью его утечки, не думаю, что мне так везло что падало именно на коварном коде

Ну как оказалось я был невнимателен, и с ядром похоже всё хорошо.
Вариант с дампом думаю да, при вновь открывшихся обстоятельствах может прокатить, поскольку слетит скорее всего именно при очередной попытке сожрать очередные 100 Мб ) Ну пока попробую так покопать, вроде область поиска сильно сузилась. Но если уж совсем упремся то и к такому варианту прибегнем

[Ivanhoe]

Снизьте частоту обработки WF раз в десять минут - никто же не умрет некоторое время, тут тогда совпадения уж точно не будет.

[FrolovAndy]

Да, попробуем, спасибо!
Надо уже точно убедиться что дело именно в этом и только в этом, чтоб сомнения энергию не забирали )

[user_ax]

А ваш workflow точно целиком стандартный?? Нет никаких переопределенных провайдеров, иерархий, подписчиков на события, в которых, в теории может быть дурной код ??

И ещё, раз в минуту - шось часто )) У нас на тестовом приложении раз в 2 минуты и всем хорошо.

[FrolovAndy]

Цитата:

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

А ваш workflow точно целиком стандартный?? Нет никаких переопределенных провайдеров, иерархий, подписчиков на события, в которых, в теории может быть дурной код ??

И ещё, раз в минуту - шось часто )) У нас на тестовом приложении раз в 2 минуты и всем хорошо.

Стандартный, но подпиленный. Вполне может быть что в этих доработках дело. Мне правда пока больше видится что проблема уже именно в нашем коде, который вызывается в результате конкретных событий. Потому что не каждая обработка воркфлоу вызывает утечки.

Мне тоже пока кажется что часто, при желании уменьшим, но пока вроде как есть нормально. Я так понимаю это было чтоб минимизировать задержки пользователей по продвижению документов, поэтому лишнее ворчание вызывать не особо хочется )

[FrolovAndy]

Почти что разобрался. Дальше думаю уже дело техники
Действительно, отжирает (и не возвращает память) один из кодов ответственных за обработку воркфлоу
WorkflowDocumentField::substitutePlaceholderAsUser, который в режиме runas вызывает уже substitutePlaceholder, и там как раз всё и происходит.
Мап, циклы, и всё как полагается, так что найдем утечку теперь, никуда не денемся )

[FrolovAndy]

Накопал причину, но в итоге опять уперся, и теперь опять очень нужны ваши советы и мнения

Итак, память расходуется и не возвращается, когда в режиме runas выполняется какой-нибудь queryRun. Точнее, после того как выполняется queryRun.next() - в этот момент в течение нескольких секунд уходит примерно 20 мб. И вернуть их ну никак не получается.

С учетом того что не под каждым пользователем такое происходит, пока напрашивается вывод что память требуется под определение прав. Не знаю, у меня пока других соображений нет, но например когда я рядового пользователя включил в группу Admin то память на его queryRun сразу перестала расходоваться.

Собственно Workflow тут и не причем как таковой, не в нем конкретно проблема, а в этой странной особенности Аксапты.

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

[SRF]

А у вас RLS используется ? Если это так, надо смотреть какой у вас билд, как минимум проблемы с памятью были до ru4.

Безопасность на уровне записей

Если rls есть и в указанном методе его отключить не критично, то можно отключить через св-во query.recordLevelSecurity(false).

Другое дело, что такая правка будет работать только в одном методе, похорошему обновить бы вам ядро, если такая возможность есть.

[FrolovAndy]

Цитата:

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

А у вас RLS используется ? Если это так, надо смотреть какой у вас билд, как минимум проблемы с памятью были до ru4.

Безопасность на уровне записей

Если rls есть и в указанном методе его отключить не критично, то можно отключить через св-во query.recordLevelSecurity(false).

Другое дело, что такая правка будет работать только в одном методе, похорошему обновить бы вам ядро, если такая возможность есть.

Да, действительно это из-за RLS. Изменение свойства для query на false для rls сразу же изменило поведение, перестали расходоваться и память, и время
Причем у нас реально RLS очень навороченный, так что я не удивляюсь в этом случае такому расходу памяти

Можно конечно и поотключать rls во всех таких ситуациях где queryRun на runas выполняется, но это для нас как самый крайний вариант. Проблема-то не в том что память расходуется, а в том что именно не возвращается когда уже не нужна процессу. Причем в этом случае никакие средства сборки мусора получается не работают, поскольку на queryRun памятью управляет ядро а не программный код. Поэтому прежде всего вопрос, может есть какие-то средства, на уровне каких-то системных процедур, которые могут принудительно дать команду освободить память? Причем как я понимаю это возможно сделать пока runas ещё работает, поскольку как только он закончится все концы наверно теряются

И насчет билдов вопрос. Наверно самым правильным в нашем случае будет и правда обновиться, и ничего не химичить.
Но я этой темой почти не владею. Поэтому начнем с простого - подскажите а как этот билд ядра определяется? Я обращался в админам, они тоже мало что знают, сказали только что установлен ServicePack 1 RollUp 5, но это для клиента. А как для АОСа тут вообще никто не знает

[Ivanhoe]

Посмотрите версию в exe клиента и AOSа - в свойствах файла. И поищите на форуме актуальные списки ядер по версиям.

[Ivanhoe]

Ядро в любом случае настойчиво рекомендуется обновить.

По RLS - если проблема в основном в WF из-за частоты запуска, то просто проверьте что ничего лишнего не будет и отключите как написали выше именно в WF / измените в принципе query.

[oip]

Цитата:

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

И поищите на форуме актуальные списки ядер по версиям.

https://aka.ms/axbuild - и там же можно скачать последний билд для AX2009 от 2018 года.

[FrolovAndy]

Цитата:

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

Посмотрите версию в exe клиента и AOSа - в свойствах файла. И поищите на форуме актуальные списки ядер по версиям.

Версию нашел, 5.0.1500.3191, из того что искал нашел только что она входит в хотфикс KB 2278963, но не смог понять к какому RU он всё таки относится, может кто навскидку сразу скажет? Этот хотфикс в основном для SharePoint 2010 как я понял

Что касается частоты запуска пакета по WF - от неё не зависит, так как если будем реже вызывать пакет то просто больше событий будет накапливаться за один раз. А уход памяти это всегда очередной вызов runas с queryRun, так что всё равно прямо пропорционально количеству событий WF
Убирать rls с queryRun - ну наверно ничего принципиально плохого не будет, в конце концов в данном контексте этот вызов используется для служебного алгоритма WF. Наверно всё будет очень банально - попробуем недельку дать WF поработать без RLS, и если ни с какими сложностями из-за этого не столкнемся то будет принято решение так и оставить )

[FrolovAndy]

Цитата:

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

https://aka.ms/axbuild - и там же можно скачать последний билд для AX2009 от 2018 года.

Спасибо огромное!
И заодно, из указанного списка получается что для нашей версии соответствует RU5 таки

[mazzy]

интересная проблема substring старых JVM.
не знаю насколько это актуально в Аксапте, надо проверять.
https://youtu.be/SZFe3m1DV1A?t=1707

суть:
substring в старых JVM не создавал новую строку, а возвращал shared область памяти из исходной строки. Поэтому исходная строка не освобождала память пока не будет освобожден substring

"известно, что это приводит к утечкам памяти. часто пользователь загружает 50Мб xml, из него выкусывает одну xml-entity размером 20 байт, ее куда-нибудь к себе в коллекцию сторит. а потом удивляется откуда у него в хипе 50мб мусора"

[FrolovAndy]

Попробовал так сделать, разными способами, наблюдения показывают что память всё равно освобождается после выхода из того кода где формировалась большая строка, даже если результат substr продолжает жить дальше
Вообще у меня такое впечатление, что реально начиная с какого-то момента в Аксапте починили все эти утечки памяти, как уж я ни крутил эксперименты с листами, мапами, перемешивая все это между клиентской и серверной частями и организовывая всякие штуки типа "один класс содержит другой класс который содержит лист классов которые содержат мапы с типом рекорд и т.д. и т.п. …" до бесконечности, как бы вся эта мешанина ни жрала память, но потом всё благополучно освобождается.
Похоже на уровне runas что-то там не докручено. И то, не знаю как это в старших версиях, под рукой их нет сейчас чтоб на них проверить. А так может в 2012 уже и runas с памятью корректно работает