Выделение памяти под процессы на сервере MS CRM

[Артем Enot Грунин]

Асинхронный сервер прожорлив и глуп по своей природе, бороться с ним опасно и бесполезно.

Хост процесс сендбокса, предположительно, обслуживает воронку событий системы, на которую подписаны изолированные плагины. Интересный момент заключается в том, что даже если плагин асинхронный, он выполняется в процессе sandbox! Честно говоря, я не особо силен во всей этой низкоуровневой процессной теме, но дебагером такой плагин ловится как при подключении как к асинхронному сервису, так и к сервису песочницы. Опять же чисто теоретически, возможно в этом и состоит природа "распухания" памяти под два этих процесса.

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

Так же рекомендую обратить внимание на то, что плагины песочницы конструируются и выполняются каждый раз при запуске плагина. Иными словами, они не могут что-либо кешировать. Если вы выполняете в них какие-то оптимизации по примеру CRM 4.0, вы только еще сильнее убиваете производительность. По поводу кеширования рекомендую следующий ресурс: http://www.avanadeblog.com/xrm/2011/...a-caching.html. Так же, последние версии SDK предлагают вам класс CachedOrganizationService который может помочь вам что-то сэкономить.

[Likefire]

Собственно, удалось немного урегулировать проблему. Вернее: две проблемы. И выделение памяти удалось отрегулировать и выяснить почему плагин падает.

С выделением памяти всё просто: по концовке плагина, когда все необходимые манипуляции исполнены и собственно, остается только сделать выход - я принудительно выполняю "обнуление" всех объявленных тяжелых переменных (списки, массивы, XML-документ). Но не просто присваиваю null, а вызываю сначала Clear() и подобные ему методы, а потом только присваиваю null (для надежности). С памятью всё стало намного лучше (Garbage Collector похоже не доходит до областей кода в плагинах).
Также, сам код плагина доработал, чтобы он не оставлял без внимания возможные исключения и информировал о том, что за исключение вынудило его упасть. Оказалось, что падает не сам плагин. Плагин срабатывает на создании сущности, а сущность создает задание рабочего процесса, который числится как дочерний, и при более чем 6-ти повторах ругается на то, что типа бесконечный цикл и всё такое. Пришлось лезть в базу и изменять параметры, как об этом говорится в следующем блоге: http://social.microsoft.com/Forums/e...e-716c8771ee78 Но я изменил не количество повторов, а MessageProcessorMinimumInactiveSeconds, поскольку воркфлоу повторяется раз в полчаса, а в настройках этот параметр равен 3600 секундам, то есть одному часу.