Tip: OutOfMemoryException Problems

Tip: OutOfMemoryException Problems

  

According to Microsoft the ASP.NET Worker Process (WP) should be configured to recycle when the first of the following limits is met :

- 60% of Physical Memory
- 800 Megabytes when using 2GB of Virtual Addressing Space (VAS)
- 1800 Megabytes when using 3GB of VAS

Failing to do this will result in the chances of OutOfMemory exceptions being raised to increase dramatically whenever certain ILASM opcodes execute (box, newarr and newobj). The only way to recover the memory is to force the recycling of the worker process by either killing it manually or restarting IIS.

Thus the following ground rules can be established :

Under 2GB VAS

- If using 1GB set the memory limit to 60%
- If using 2GB set the memory limit to 40%
- If using 4GB set the memory limit to 20%

Under 3GB VAS

- If using 1GB set the memory limit to 60%
- If using 2GB set the memory limit to 60%
- If using 4GB set the memory limit to 44%

This translates in the following scenarios for each OS running .NET FX 1.1 when webGarden=false (the default value) :

Windows 2000 Server : Only 2GB VAS is available. No worker process isolation possible.
Windows 2000 Advanced Server (or better) : Use 3GB VAS. No worker process isolation possible.
Windows 2003 Web or Standard Edition : Only 2GB VAS is available. Use application pools to isolate applications into separate ASP.NET worker processes.
Windows 2003 Enterprise Edition (or better) : Choose 2GB or 3GB VAS. Use application pools to isolate applications into separate ASP.NET worker processes.

It is also possible to mitigate this problem by setting WebGarden to true which will create a worker process for each CPU bit that is set in CPUMask (regardless of OS version as long as the OS supports more than 1 CPU).

This doesn't mean we shouldn't have more than 1GB of memory. Whenever a recycle occurs ASP.NET/IIS will try to create a new process to handle the load while it's trying to kill the previous one. So to avoid paging it's better to have enough memory to hold both worker processes in memory, otherwise, we will take a large performance hit. Also, when under normal operating conditions you have multiple worker processes you should have enough memory to hold all the worker processes in memory, our services and still allow for one or two WP's to recycle peacefully.

When planning the Deployment Controller machine, special care should be taken as the lack of system memory that may occur during compilation can have a performance hit due to paging on the other processes in the same machine therefore slowing requests handling in that machine.

You can read the original Microsoft article that explains with some more detail the memory counters involved, as well as other very interesting monitoring information and is entitled :
ASP.NET Performance Monitoring, and When to Alert Administrators

Regards