AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.01.2020, 12:38   #1  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
DAX2009 забирает всю память
Проблема следующая. Процесс Ax32Serv.exe постепенно съедает всю имеющуюся на сервере память, около 32 Гб. В течение нескольких дней это происходит. Приходится из-за этого периодически перезапускать АОС, только это помогает освободить память.
Причем происходит это только на основном АОСе. Есть также и пакетный АОС, соответственно физически на другой машине, и там ничего не уходит.

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

Есть ли какая-то методология, подходы, по шагам, как выявить откуда эта проблема идёт? Нас двое человек по AX, но мы чисто программеры, и все эти вопросы где уже идёт взаимодействие с операционной системой, к сожалению нет у нас этих компетенций. Админы наши по AX имеют также самое общее понимание, необходимое для того чтоб всё работало.
Поэтому без советов опытных людей мы тут не решим, без вариантов.
Очень прошу посоветуйте кто что знает. Думаю есть кто также сталкивались с такой ситуацией. Может просто по ссылкам по рекомендуете какие-то вещи изучить. Любая полезная информация подойдёт. Потому что пока даже не понимаем с какого бока подступиться.
Старый 15.01.2020, 13:03   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
для начала проверьте размер глобального кэша на сервере
Поговорим о глобальных кэшах в Аксапте? Как правильно?
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: FrolovAndy (1).
Старый 15.01.2020, 13:15   #3  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А есть поддержка в MS? Можно завести тикет, они научат собирать дамп AOS, там можно будет посмотреть какая операция заняла столько памяти. Возможно, есть описание сбора дампа и в открытом доступе, уже не помню про 2009.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: FrolovAndy (1).
Старый 15.01.2020, 13:34   #4  
Pandasama is offline
Pandasama
Участник
 
448 / 133 (5) +++++
Регистрация: 11.08.2014
Адрес: Барнаул
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А есть поддержка в MS
а по 2009 ещё осталась какая-то поддержка?
Старый 15.01.2020, 14:05   #5  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от Pandasama Посмотреть сообщение
а по 2009 ещё осталась какая-то поддержка?
Вендор перестает саомтоятельно делать фиксы (хотя в некоторых случаях выпускает), но остальную поддержку никто не отменял.
__________________
Ivanhoe as is..
Старый 15.01.2020, 14:34   #6  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Была точно такая же проблема лет десять назад, помню что помогла установка более старшей версии Ax32serv.exe, информация о таком варианте решения была получена от партнера (КК). Спросите вашего партнера, возможно для них это уже известный случай.
Старый 16.01.2020, 11:01   #7  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Цитата:
Сообщение от mazzy Посмотреть сообщение
для начала проверьте размер глобального кэша на сервере
Поговорим о глобальных кэшах в Аксапте? Как правильно?
А размер как-то определяется, или надо просто посмотреть что вообще в этом кэше лежит?
Я попробовал тупо с помощью джоба оценить, пробежался по Infolog.globalCache(), appl, и classFactory, посмотрел что там лежит, закэшировано совсем немного, и главное что со временем содержание не меняется.
Похоже активного использования нет.

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

Последний раз редактировалось FrolovAndy; 16.01.2020 в 11:05.
Старый 16.01.2020, 11:04   #8  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А есть поддержка в MS? Можно завести тикет, они научат собирать дамп AOS, там можно будет посмотреть какая операция заняла столько памяти. Возможно, есть описание сбора дампа и в открытом доступе, уже не помню про 2009.
Спасибо большое, попробуем!
Скорее всего придется самостоятельно, штат тут уже несколько раз сменился, концов не найти, даже неизвестно есть ли тут какая-то поддержка.
Но очень надеюсь что удастся найти инфу про сбор дампа
Старый 16.01.2020, 11:23   #9  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Я про поддержку Microsoft. Если вы оплачиваете подписку, то у вас она есть. Если нет - ищите про дампы. Если АОС именно кушает память, 95% что это не корректная доработка. Как выше уже написали, стоит для начала обновить kernel до последнего рекомендуемого, ищите тут же на форуме (ну и скачать можно будет опять же при наличии подписки).
__________________
Ivanhoe as is..
Старый 16.01.2020, 12:03   #10  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от FrolovAndy Посмотреть сообщение
Но очень надеюсь что удастся найти инфу про сбор дампа
emeadaxsupport: Finding the X++ call stack that caused a crash
За это сообщение автора поблагодарили: FrolovAndy (1).
Старый 16.01.2020, 12:04   #11  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
95% что это не корректная доработка.
Проблемы с памятью бывают при некорректной работе с List и Map. Хотя если команда менялась и концов не найти - то вам будет сложно искать подобный баг в доработках, о которых вы не знаете ничего.
Старый 16.01.2020, 12:09   #12  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Как выяснилось, поддержки у нас нет сто процентов, сейчас специально поузнавал у ребят, оказывается у них когда-то уже была идея в MS обратиться по этому поводу, но именно из-за отсутствия поддержки не смогли

Так что будем пока с дампом работать.
Вообще очень похоже что проблема вызывается узким кругом лиц, может быть даже конкретным пользователем (точнее криво написанным кодом, который именно этим человеком используется). Потому что характер прироста памяти очень нелинейный. В течение дня в какие-то периоды очень сильно растет, а в остальные вяло увеличивается. В выходные не увеличивается. Будем пытаться как-то через это тоже искать решение
Старый 16.01.2020, 12:13   #13  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
MS нужен был для помощи с дампом. Выше уже привели ссылку, сможете и сами. Там будет видно стек вызовов, пользователя. Исходя из этого найдете свою доработку.
__________________
Ivanhoe as is..
Старый 16.01.2020, 12:14   #14  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Цитата:
Сообщение от Zabr Посмотреть сообщение
Проблемы с памятью бывают при некорректной работе с List и Map. Хотя если команда менялась и концов не найти - то вам будет сложно искать подобный баг в доработках, о которых вы не знаете ничего.
Была такая мысль, но там же всё чистится потом. Я специально пробовал код который очень круто раздувал Map до больших объемов. Действительно, в процессе исполнения кода, памяти уходило много, но потом как только всё заканчивалось, память сразу же освобождалась
Пробовал такую же тему с темповыми таблицами, но тоже потом всё чистится

То есть тут что-то забирает память и потом не освобождает. Есть еще мысли что кэширование записей кривое, например неправильно сделали CacheLookup. Это тоже попробуем поискать
Старый 16.01.2020, 12:16   #15  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Цитата:
Огромное спасибо!!!
Обязательно попробуем
Старый 17.01.2020, 15:20   #16  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Итак, по дампу...
Я вообще понял исходя из информации по ссылке, что речь идет о ситуации когда АОС по непонятным причинам валится, и для этого предлагается добиться образования дампа на момент падения, и дальше по стеку вызовов в нем уже отмотать до информации о том что это падение вызвало. Так?

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

Короче, что там можно сделать? уже мозг кипит )
Старый 17.01.2020, 17:02   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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 вам в помощь.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 17.01.2020 в 17:20.
За это сообщение автора поблагодарили: FrolovAndy (1), Товарищ ♂uatr (2).
Старый 17.01.2020, 19:14   #18  
FrolovAndy is offline
FrolovAndy
Участник
 
71 / 45 (2) +++
Регистрация: 13.09.2007
Спасибо огромное за содержательный ответ, и за то что пишете на очень понятном языке! Очень хорошо выделены основные принципы

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

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

Сосредоточу всё свое внимание на том что вы пишете про самозамкнутые хранилища, воспользуюсь классом SysHeapLog про который до сегодняшнего дня вообще ничего не знал. Будем копать дальше!
За это сообщение автора поблагодарили: mazzy (2).
Старый 17.01.2020, 22:21   #19  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Подтверждаю подозрения про списки хранящие записи табличного типа. Что-то явно не чисто в системе при работе с такими динамическими структурами. Место они в памяти очень много занимают. И про сборщик мусора подтверждаю. В особо заковыристых случаях пока явно в ссылку Null не запишешь она живёт в памяти до последнего.

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

По вашей ситуации. Вы не пробовали как-то локализовать проблему? Вычислить при использовании какого именно функционала АОС начинает есть память? У вас все пользователи работают через один АОС? Можно попробовать поднять ещё один АОС и поделить между ними пользователей по функциональным задачам. Возможно удастся вычислить при работе какого функционала начинает съедается память
Старый 20.01.2020, 08:52   #20  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
не надо лезть на уровень windbg

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



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

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

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

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
DAX "съедает" всю память при запуске AOT NataLee DAX: Администрирование 12 17.09.2012 11:23
SQL с базой Axapta занимает всю оперативную память alesander DAX: Администрирование 9 23.06.2010 12:45
А построение перекрестных ссылок опять сожрет всю память и завесит систему нафих Alex_K DAX: Администрирование 15 04.09.2009 22:00
Вопросы по OLAP в DAX2009 oleg_e DAX: Функционал 9 10.12.2008 02:02
Очистить память после разноски журнала ОС npokypatop DAX: Программирование 7 25.06.2008 17:03
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:49.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.