Книга продаж/покупок

[_AxDevel_]

Dynamics AX 4.0, ядро 4.0.2501.116
Запускаю обновление книги продаж. Процесс выполняется долго, это все знают. При расчёте запускаются классы семейства BookDataCalc*, которые выполняются на сервере. В классах создаётся много cherneh в памяти: set-ы, map-ы, recordsortedlist-ы и т.п. Так вот этот серверный код потихоньку начинает съедать память, после выполнения память не вся освобождается. Интересует вопрос такой: если разорвалась связь клиент-сервер, или возникла ошибка при серверном расчёте, то как сборщик мусора обрабатывает такую ситуацию для освобождения выделенной памяти? Пока лечится рестартом аоса. Очень актуально.

[samolalex]

Обсуждение принципов работы "сборщика мусора" велось здесь
ИМХО. По поводу, данной ситуации, приходят на ум такие варианты как:
1) Очистка кэша (сервис->очистка кэша или удаление файлов *.aoc)
2) Запуск операции в системе с двухуровневым вариантом архитектуры;
3) Запуск операции на сервере посредством удаленного подключения.

[_AxDevel_]

Цитата:

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

Обсуждение принципов работы "сборщика мусора" велось здесь
ИМХО. По поводу, данной ситуации, приходят на ум такие варианты как:
1) Очистка кэша (сервис->очистка кэша или удаление файлов *.aoc)
2) Запуск операции в системе с двухуровневым вариантом архитектуры;
3) Запуск операции на сервере посредством удаленного подключения.

Вы предлагаете лечить симптомы, а не причины.

[samolalex]

Из этого сообщения:

Цитата:

Объект считается неиспользуемым, если счетчик указателей на этот объект стал равен 0.

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

    HeapCheck   hc;

    try
    {
        //Операция обновления книги продаж
    }
    catch(Exception::Error)
    {
        hc.shrinkPool();
        //...
    }

[_AxDevel_]

Цитата:

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

Из этого сообщения:

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

    HeapCheck   hc;

    try
    {
        //Операция обновления книги продаж
    }
    catch(Exception::Error)
    {
        hc.shrinkPool();
        //...
    }

У меня вот вопрос, кто отвечает за очистку памяти: винда, сама аксапта, CLR? При создании большого числа объектов с последующим их удалением получаем фрагментированную кучу на аосе. Может быть, это служит причиной роста занимаемой аосом памяти?

[samolalex]

Цитата:

У меня вот вопрос, кто отвечает за очистку памяти: винда, сама аксапта, CLR?

Насколько я понял из прочитанного в других темах, посвященных управлению памятью, в Axapta используется "сторонний" (т.е. используемый не только в Ax) менеджер управления памятью SmartHeap. Сайт производителя

Цитата:

При создании большого числа объектов с последующим их удалением получаем фрагментированную кучу на аосе. Может быть, это служит причиной роста занимаемой аосом памяти?

Может быть. Возможные варианты решения проблемы:
1) Попробуйте изменить критерий начала сборки мусора (Сервис\Параметры\Разработка\Критерий начала сборки мусора)
2) Сделайте дефрагментацию кучи через форму SysHeapCheck.

[_AxDevel_]

Цитата:

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

Насколько я понял из прочитанного в других темах, посвященных управлению памятью, в Axapta используется "сторонний" (т.е. используемый не только в Ax) менеджер управления памятью SmartHeap. Сайт производителя

Может быть. Возможные варианты решения проблемы:
1) Попробуйте изменить критерий начала сборки мусора (Сервис\Параметры\Разработка\Критерий начала сборки мусора)
2) Сделайте дефрагментацию кучи через форму SysHeapCheck.

1-2 - не помогло. Уточнение: класс BookDataCalc_Purch_Process_RU

[_AxDevel_]

Цитата:

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

1-2 - не помогло. Уточнение: класс BookDataCalc_Purch_Process_RU

там активно используется RecordSortedList в качестве буфера.
MSDN пишет так:
There is no limit to the size of a RecordSortedList object, but they are completely memory-based, so there are potential memory consumption problems.

[_AxDevel_]

Цитата:

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

там активно используется RecordSortedList в качестве буфера.
MSDN пишет так:
There is no limit to the size of a RecordSortedList object, but they are completely memory-based, so there are potential memory consumption problems.

Почему после завершения работы класса память, выделенная под объект RecordSortedList не возвращается в ОС? Проверил, ссылок на данный экземпляр RecordSortedList в процессе выполнения больше не остается. Таким образом при периодических запусках расчёта получаем разрастание используемой оасом памяти. Тестовый пример по заполнению RecordSortedList записями FactureJour_RU в количестве 100000 показал увеличение памяти, используемой аосом, при каждом запуске на 160 МБ.