BizTalk Out of Memory Exceptions
Interesting articles to read concerning the standard out of memory exception and how to diagnose and reduce the effects of the problem:
The BizTalk service restarts unexpectedly when you map large messages in BizTalk Server 2004
Memory Growth in BizTalk Messaging
How to Capture a Memory Dump of a BizTalk Process
Other related
Format of BizTalk 2004 assemblies: How do artifacts get compiled to .NET assemblies
Format of BizTalk 2004 assemblies: Maps
Sometims putting things in the GAC isn't such a good idea as is suggested here
When discussing with some colleagues I collated the following information.
When you start the application, initially the BizTalk process starts, and consumes some memory. Then, when you start an orchestration, each of the schema and map DLLs, and the orchestration DLLs will be JIT’d and loaded. Memory may not be reclaimed until you cycle the BTS process. Next, instance data is loaded. For an orchestration with a couple of schemas and a map to convert, this is 2x DOM 1x XSLT, plus additional data kept about the XSLT as noted below.
If your memory is fragmented, or the BizTalk memory watermarks are not appropriate, you could well run out of memory even when you have adequate memory available.
Running out of memory and running out of memory address space are two completely different issues. It doesn’t matter how much memory is present in the box, 4Gb, 32Gb or even a terabyte, 32bit processes (processes, not processors) each only have 2Gb of memory addressed to them for usage. In managed code, the .Net runtime may up a proportion of that 2Gb. So in reality, the amount of memory available is more likely to be about 1 to 1.2 Gb. This is one of the reasons way for example ASP.Net app can be run in separate apppools and one of the reasons why BizTalk allows multiple hosts.
So in summary be aware of
1) High and Low WaterMarks (see BizTalk Performance white paper)
2) Available memory (is it hitting a memory limit)
3) Which orchestrations are using the most memory and consider using isolated hosts
Some user groups result in this recommendation on shutdowns:
The BizTalk service restarts unexpectedly when you map large messages in BizTalk Server 2004
Memory Growth in BizTalk Messaging
How to Capture a Memory Dump of a BizTalk Process
Other related
Format of BizTalk 2004 assemblies: How do artifacts get compiled to .NET assemblies
Format of BizTalk 2004 assemblies: Maps
Sometims putting things in the GAC isn't such a good idea as is suggested here
When discussing with some colleagues I collated the following information.
When you start the application, initially the BizTalk process starts, and consumes some memory. Then, when you start an orchestration, each of the schema and map DLLs, and the orchestration DLLs will be JIT’d and loaded. Memory may not be reclaimed until you cycle the BTS process. Next, instance data is loaded. For an orchestration with a couple of schemas and a map to convert, this is 2x DOM 1x XSLT, plus additional data kept about the XSLT as noted below.
If your memory is fragmented, or the BizTalk memory watermarks are not appropriate, you could well run out of memory even when you have adequate memory available.
Running out of memory and running out of memory address space are two completely different issues. It doesn’t matter how much memory is present in the box, 4Gb, 32Gb or even a terabyte, 32bit processes (processes, not processors) each only have 2Gb of memory addressed to them for usage. In managed code, the .Net runtime may up a proportion of that 2Gb. So in reality, the amount of memory available is more likely to be about 1 to 1.2 Gb. This is one of the reasons way for example ASP.Net app can be run in separate apppools and one of the reasons why BizTalk allows multiple hosts.
So in summary be aware of
1) High and Low WaterMarks (see BizTalk Performance white paper)
2) Available memory (is it hitting a memory limit)
3) Which orchestrations are using the most memory and consider using isolated hosts
Some user groups result in this recommendation on shutdowns:
Not sure why the BTS NT service shuts down; but the best way to monitor
this is using MOM. You can set alerts in MOM to monitor the service status
and trigger various actions depending on the situation.
http://www.microsoft.com/mom/default.mspx
posted by David @ 8:30 am
0 Comments:
Post a Comment
<< Home