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

[FrolovAndy]

Проблема следующая. Процесс Ax32Serv.exe постепенно съедает всю имеющуюся на сервере память, около 32 Гб. В течение нескольких дней это происходит. Приходится из-за этого периодически перезапускать АОС, только это помогает освободить память.
Причем происходит это только на основном АОСе. Есть также и пакетный АОС, соответственно физически на другой машине, и там ничего не уходит.

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

Есть ли какая-то методология, подходы, по шагам, как выявить откуда эта проблема идёт? Нас двое человек по AX, но мы чисто программеры, и все эти вопросы где уже идёт взаимодействие с операционной системой, к сожалению нет у нас этих компетенций. Админы наши по AX имеют также самое общее понимание, необходимое для того чтоб всё работало.
Поэтому без советов опытных людей мы тут не решим, без вариантов.
Очень прошу посоветуйте кто что знает. Думаю есть кто также сталкивались с такой ситуацией. Может просто по ссылкам по рекомендуете какие-то вещи изучить. Любая полезная информация подойдёт. Потому что пока даже не понимаем с какого бока подступиться.

[mazzy]

для начала проверьте размер глобального кэша на сервере
Поговорим о глобальных кэшах в Аксапте? Как правильно?

[Ivanhoe]

А есть поддержка в MS? Можно завести тикет, они научат собирать дамп AOS, там можно будет посмотреть какая операция заняла столько памяти. Возможно, есть описание сбора дампа и в открытом доступе, уже не помню про 2009.

[Pandasama]

Цитата:

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

А есть поддержка в MS

а по 2009 ещё осталась какая-то поддержка?

[Ivanhoe]

Цитата:

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

а по 2009 ещё осталась какая-то поддержка?

Вендор перестает саомтоятельно делать фиксы (хотя в некоторых случаях выпускает), но остальную поддержку никто не отменял.

[Zabr]

Была точно такая же проблема лет десять назад, помню что помогла установка более старшей версии Ax32serv.exe, информация о таком варианте решения была получена от партнера (КК). Спросите вашего партнера, возможно для них это уже известный случай.

[FrolovAndy]

Цитата:

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

для начала проверьте размер глобального кэша на сервере
Поговорим о глобальных кэшах в Аксапте? Как правильно?

А размер как-то определяется, или надо просто посмотреть что вообще в этом кэше лежит?
Я попробовал тупо с помощью джоба оценить, пробежался по Infolog.globalCache(), appl, и classFactory, посмотрел что там лежит, закэшировано совсем немного, и главное что со временем содержание не меняется.
Похоже активного использования нет.

Или есть какой-то более грамотный способ оценки размера глобального кэша?

[FrolovAndy]

Цитата:

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

А есть поддержка в MS? Можно завести тикет, они научат собирать дамп AOS, там можно будет посмотреть какая операция заняла столько памяти. Возможно, есть описание сбора дампа и в открытом доступе, уже не помню про 2009.

Спасибо большое, попробуем!
Скорее всего придется самостоятельно, штат тут уже несколько раз сменился, концов не найти, даже неизвестно есть ли тут какая-то поддержка.
Но очень надеюсь что удастся найти инфу про сбор дампа

[Ivanhoe]

Я про поддержку Microsoft. Если вы оплачиваете подписку, то у вас она есть. Если нет - ищите про дампы. Если АОС именно кушает память, 95% что это не корректная доработка. Как выше уже написали, стоит для начала обновить kernel до последнего рекомендуемого, ищите тут же на форуме (ну и скачать можно будет опять же при наличии подписки).

[Logger]

Цитата:

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

Но очень надеюсь что удастся найти инфу про сбор дампа

emeadaxsupport: Finding the X++ call stack that caused a crash

[Zabr]

Цитата:

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

95% что это не корректная доработка.

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

[FrolovAndy]

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

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

[Ivanhoe]

MS нужен был для помощи с дампом. Выше уже привели ссылку, сможете и сами. Там будет видно стек вызовов, пользователя. Исходя из этого найдете свою доработку.

[FrolovAndy]

Цитата:

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

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

Была такая мысль, но там же всё чистится потом. Я специально пробовал код который очень круто раздувал Map до больших объемов. Действительно, в процессе исполнения кода, памяти уходило много, но потом как только всё заканчивалось, память сразу же освобождалась
Пробовал такую же тему с темповыми таблицами, но тоже потом всё чистится

То есть тут что-то забирает память и потом не освобождает. Есть еще мысли что кэширование записей кривое, например неправильно сделали CacheLookup. Это тоже попробуем поискать

[FrolovAndy]

Цитата:

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

emeadaxsupport: Finding the X++ call stack that caused a crash

Огромное спасибо!!!
Обязательно попробуем

[FrolovAndy]

Итак, по дампу...
Я вообще понял исходя из информации по ссылке, что речь идет о ситуации когда АОС по непонятным причинам валится, и для этого предлагается добиться образования дампа на момент падения, и дальше по стеку вызовов в нем уже отмотать до информации о том что это падение вызвало. Так?

У меня просто иная ситуация. Ничего как таковое не падает. Точнее в потенциале наверное таки и упадет если АОС вовремя не рестартовывать. Но идея в другом. Тут надо понять именно не момент в который что-то падает, а выяснить что так влияет на утечку памяти.
Ну я пробовал всяко-разно пытаться действовать хотя бы согласно указанной информации. Дамп собрал просто на текущем работающем процессе, открыл в WinDbg, ну и уже после выполнения команды kp понимаю что не знаю как дальше действовать. В разбираемом примере указывается конкретный фрейм, по которому и определяется всё остальное, в моём случае такого фрейма нет, и вообще информация выходит менее осмысленная. Я так понял что это тоже про AOS crash, т.е. не про мой случай
Есть идеи, советы, что я могу полезного с помощью windbg вытащить? почитал его описание команд, понял что надо первоначально знать какие шаги выполнять, методология что ли какая-то...

Короче, что там можно сделать? уже мозг кипит )

[mazzy]

Цитата:

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

Есть идеи, советы, что я могу полезного с помощью windbg вытащить? почитал его описание команд, понял что надо первоначально знать какие шаги выполнять, методология что ли какая-то...

не надо лезть на уровень windbg

это уровень ядра и C++. все равно на этом уровне вы ничего сделать не сможете, только версию ядра обновить (обновите exe-шники по-любому)

бизнес-логика аксапты находится на уровне Java виртуальной машины (JVM)
JVM в аксапте была форкнута очень давно. там версия Java максимум 2-3. Точно меньше Java 6.

Поэтому вам нужно копать проблемы старенькой Java.
Прежде всего сборщик мусора (GC)

В Java память не "течет". В Java "память не освобождается сборщиком мусора".
В стареньких Java сборщик мусора прибирает объект, если на него нет ссылок из других объектов.

следовательно вам нужно искать:
1. объекты, на которые ссылаются глобальные "вечноживущие" объекты: GlobalCache, Infolog, Appl и другие
2. объекты, которые образуют нетривиальное кольцо (кольцо, в котором больше двух объектов) - самосвязанные списки, самозамкнутые мапы и прочее. Причем эти объекты не помечаются как dead. В общем, читать про достижимые и мертвые объекты в java

Я читал ваше утверждение что ваш GlobalCache маленький
Но проверьте себя еще раз. Вы точно читали кэш СЕРВЕРА, а не клиента?
среди закэшированных объектов нет каких-нибудь map'ов, которые содержат record?

например, так стандартный функционал корпоративного портала хранит в GlobalCache картинки. Влегкую.

если GlobalCache на СЕРВЕРЕ действительно не содержит объемных данных,
то остается искать недостижимые для сборщика мусора мертвые объекты в ваших модификациях.

и класс SysHeapLog вам в помощь.

[FrolovAndy]

Спасибо огромное за содержательный ответ, и за то что пишете на очень понятном языке! Очень хорошо выделены основные принципы

Большое облегчение честно говоря что не надо шаманить с дампом.

Глобальный кэш я именно на сервере смотрел, то есть вызовы *.globalCache() делались из кода исполняющегося на сервере. Ну разве что classFactory.globalCache() я смотрел и там и там, читал на форуме такой совет что его надо на обоих звеньях анализировать
Вот, просмотрел полностью, разбирая все сложные объекты в том числе и мапы в мапах, и не считая пары контейнеров с 400 числами ничего мощного там не было. Я почему и спросил нет ли каких-то альтернативных способов оценки глобального кэша, т.к. я просто перебирал содержимое и всё, это не дало ничего настораживающего

Сосредоточу всё свое внимание на том что вы пишете про самозамкнутые хранилища, воспользуюсь классом SysHeapLog про который до сегодняшнего дня вообще ничего не знал. Будем копать дальше!

[S.Kuskov]

Подтверждаю подозрения про списки хранящие записи табличного типа. Что-то явно не чисто в системе при работе с такими динамическими структурами. Место они в памяти очень много занимают. И про сборщик мусора подтверждаю. В особо заковыристых случаях пока явно в ссылку Null не запишешь она живёт в памяти до последнего.

Были на практике такие случаи. Падает AOS при расчёте спецификации

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

[belugin]

Цитата:

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

не надо лезть на уровень windbg

это уровень ядра и C++. все равно на этом уровне вы ничего сделать не сможете, только версию ядра обновить (обновите exe-шники по-любому)

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

Цитата:

JVM в аксапте была форкнута очень давно.

Она там не форкнута - там свой сборщик мусора который работает по другим принципам - подсчет ссылок вместо mark and sweep. Из-за этого не надо явно финализировать объекты (они собираются сразу после пропадания последней ссылки), но в случае циклических ссылок может быть проблема с тем, что сборщик мусора работает слишком долго.

Еще есть сложность с распределенной сборкой мусора - клиент может хранить ссылку на объект на сервере и может быть распределенный цикл, который собирается как-то очень нетривиально и долго. В Ax2012, ЕМНИП, специально устраняли такие ссылки.

Я не очень знаю, как при помощи WinDBG исследовать unmanaged память, но я знаю что, по крайней мере, в Dyn365FO есть performance counters для количества объектов, сборок мусора и так далее. Может быть что-то такое есть и в 2009 и оно как-то поможет в исследовании проблемы. В доке по 2012, впрочем, я их не вижу