|
23.07.2012, 10:28 | #1 |
Участник
|
Книга продаж/покупок
Dynamics AX 4.0, ядро 4.0.2501.116
Запускаю обновление книги продаж. Процесс выполняется долго, это все знают. При расчёте запускаются классы семейства BookDataCalc*, которые выполняются на сервере. В классах создаётся много cherneh в памяти: set-ы, map-ы, recordsortedlist-ы и т.п. Так вот этот серверный код потихоньку начинает съедать память, после выполнения память не вся освобождается. Интересует вопрос такой: если разорвалась связь клиент-сервер, или возникла ошибка при серверном расчёте, то как сборщик мусора обрабатывает такую ситуацию для освобождения выделенной памяти? Пока лечится рестартом аоса. Очень актуально. |
|
23.07.2012, 11:58 | #2 |
Участник
|
Обсуждение принципов работы "сборщика мусора" велось здесь
ИМХО. По поводу, данной ситуации, приходят на ум такие варианты как: 1) Очистка кэша (сервис->очистка кэша или удаление файлов *.aoc) 2) Запуск операции в системе с двухуровневым вариантом архитектуры; 3) Запуск операции на сервере посредством удаленного подключения.
__________________
С уважением, Александр. |
|
23.07.2012, 15:14 | #3 |
Участник
|
Цитата:
Сообщение от samolalex
Обсуждение принципов работы "сборщика мусора" велось здесь
ИМХО. По поводу, данной ситуации, приходят на ум такие варианты как: 1) Очистка кэша (сервис->очистка кэша или удаление файлов *.aoc) 2) Запуск операции в системе с двухуровневым вариантом архитектуры; 3) Запуск операции на сервере посредством удаленного подключения. |
|
23.07.2012, 17:43 | #4 |
Участник
|
Из этого сообщения:
Цитата:
Объект считается неиспользуемым, если счетчик указателей на этот объект стал равен 0.
Таким образом, мне кажется, для устранения вышеуказанной проблемы можно реализовать конструкцию вроде этой: X++: HeapCheck hc; try { //Операция обновления книги продаж } catch(Exception::Error) { hc.shrinkPool(); //... }
__________________
С уважением, Александр. |
|
24.07.2012, 09:19 | #5 |
Участник
|
Цитата:
Сообщение от samolalex
Из этого сообщения:
Поэтому, скорее всего, при разрывах связи счетчики указателей на неиспользуемые объекты не сбрасываются. Поэтому в этой ситуации следует каким-либо образом в случае возникновения ошибки очищать неиспользуемую память посредством метода shrinkPool() класса HeapCheck, предназначенного для управления памятью в Аксапта. Таким образом, мне кажется, для устранения вышеуказанной проблемы можно реализовать конструкцию вроде этой: X++: HeapCheck hc; try { //Операция обновления книги продаж } catch(Exception::Error) { hc.shrinkPool(); //... } |
|
24.07.2012, 10:10 | #6 |
Участник
|
Цитата:
У меня вот вопрос, кто отвечает за очистку памяти: винда, сама аксапта, CLR?
Цитата:
При создании большого числа объектов с последующим их удалением получаем фрагментированную кучу на аосе. Может быть, это служит причиной роста занимаемой аосом памяти?
1) Попробуйте изменить критерий начала сборки мусора (Сервис\Параметры\Разработка\Критерий начала сборки мусора) 2) Сделайте дефрагментацию кучи через форму SysHeapCheck.
__________________
С уважением, Александр. Последний раз редактировалось samolalex; 24.07.2012 в 10:13. |
|