Jun 11, 2008

Memory Leak using Biztalk mapper

In one of our ESB projects that I worked on with my team we encountered on a huge memory leak issue with biztalk projects. In our project we had a couple orchestrations and maps (simple, only text functoids).
The problem was that after running the map the first time the memory usage jumped for 200-300 MB. After working on 4/5 messages the biztalk host service took about 2 GB of memory. And with no load at all messages began to stuck. Messages run into message box but no dequeue was made at all (Tracking DB).
The messages was about 1-2 kb size and the orchestration was standart work flow, without any looping.


After some resarch made by us and my work colegue Matanya Weinshtock that found the next kb :
http://support.microsoft.com/kb/918643

summary of it :

The System.Policy.Security.Evidence object is often used in transforms and can consume a lot of memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted.Most of the default BizTalk functoids are implemented as inline script. These items can cause System.Byte[] objects to collect in memory.

Suggested Solution by Microsoft

To minimize memory consumption, we recommend that you put any map that uses these functoids into a small assembly. Then, reference that assembly.


The Solution

We decided not split each map to different assemblybecause as you can see at kb almost all of the functoids are implemented with inline scripts.
I suggest the next develop metodology with biztalk project :

Alwayes split the project to at least three projects :

  1. Schema project.
  2. Maps project.
  3. Orchestration project.

with this develop metodology we succeded to almost stop the leaking at all.

Again don't take biztalk as It is simple and supposed to work, always check it.


No comments: