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

[Likefire]

Печальная история
Некоторое время назад заметил, что с определенной периодичностью начал "отваливаться" один из workflow-процессов с описанием ошибки "Недопустимый тип получателя". Ошибка возникает на шаге, который вызывает создание новой кастомной сущности, на которой работает очень хитрый и развесистый PreCreate-плагин. Стал думать и гадать, разбираться так и сяк - в ручном режиме ошибка не отлавливается: всё работает с первого раза. Но суть не в самой ошибке, а в попытках обнаружения её источника. В процессе наблюдения и разбора обнаружилось, что на сервере CRM (single server) происходит нехилое выделение памяти под процессы:

- Microsoft CRM Asynchronous Processing Service (один из двух), и
- Microsoft.Crm.Sandbox.HostService

Отмечу, что в общих масштабах сервера в принципе, выделяемая память не занимает какое-то критичное пространство - около 20% всего, да и Microsoft.Crm.Sandbox.HostService периодически "ужимается" до исходного состояния. Но вот Asynchronous Processing Service реально беспокоит - за три цикла выполнения указанного workflow (трижды подряд он срабатывает), выделямая память возросла с 300 460 К до 544 924 К.
Подозреваю, что код плагина должен содержать какие-нить Dispose или что-то вроде. Но что делать конкретно, непонятно, поэтому, если кто знает ответы на вопросы (смотрим ниже) или даже знает источник, из которого можно прочесть что-то,- буду благодарен за помощь.
Вопросы:
1. Что влияет на выделение памяти под указанные процессы?
2. Как правильно организовать программные ресурсы плагина для того, чтобы избежать утечек?
3. Хотелось бы понимать: за что отвечает процесс Microsoft.Crm.Sandbox.HostService и какие выводы можно сделать, если под данный процесс выделяется память?

[Артем 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 секундам, то есть одному часу.