|
17.01.2020, 15:20 | #1 |
Участник
|
Итак, по дампу...
Я вообще понял исходя из информации по ссылке, что речь идет о ситуации когда АОС по непонятным причинам валится, и для этого предлагается добиться образования дампа на момент падения, и дальше по стеку вызовов в нем уже отмотать до информации о том что это падение вызвало. Так? У меня просто иная ситуация. Ничего как таковое не падает. Точнее в потенциале наверное таки и упадет если АОС вовремя не рестартовывать. Но идея в другом. Тут надо понять именно не момент в который что-то падает, а выяснить что так влияет на утечку памяти. Ну я пробовал всяко-разно пытаться действовать хотя бы согласно указанной информации. Дамп собрал просто на текущем работающем процессе, открыл в WinDbg, ну и уже после выполнения команды kp понимаю что не знаю как дальше действовать. В разбираемом примере указывается конкретный фрейм, по которому и определяется всё остальное, в моём случае такого фрейма нет, и вообще информация выходит менее осмысленная. Я так понял что это тоже про AOS crash, т.е. не про мой случай Есть идеи, советы, что я могу полезного с помощью windbg вытащить? почитал его описание команд, понял что надо первоначально знать какие шаги выполнять, методология что ли какая-то... Короче, что там можно сделать? уже мозг кипит ) |
|
17.01.2020, 17:02 | #2 |
Участник
|
Цитата:
это уровень ядра и 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 вам в помощь. Последний раз редактировалось mazzy; 17.01.2020 в 17:20. |
|
|
За это сообщение автора поблагодарили: FrolovAndy (1), Товарищ ♂uatr (2). |
20.01.2020, 08:52 | #3 |
Участник
|
Цитата:
Цитата:
JVM в аксапте была форкнута очень давно.
Еще есть сложность с распределенной сборкой мусора - клиент может хранить ссылку на объект на сервере и может быть распределенный цикл, который собирается как-то очень нетривиально и долго. В Ax2012, ЕМНИП, специально устраняли такие ссылки. Я не очень знаю, как при помощи WinDBG исследовать unmanaged память, но я знаю что, по крайней мере, в Dyn365FO есть performance counters для количества объектов, сборок мусора и так далее. Может быть что-то такое есть и в 2009 и оно как-то поможет в исследовании проблемы. В доке по 2012, впрочем, я их не вижу |
|