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

[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 вам в помощь.

[belugin]

Цитата:

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

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

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

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

Цитата:

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

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

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

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