IIS7/.NET Memory Leaking – Is Worker Process Recycling The Only Long Term Fix

IIS Optimization and Performance Tuning is quite a broad topic, and your bottleneck(s) could be several places.

First, you can better determine what your bottlenecks are by using the Performance Monitor.

Based on what you find there, you can move on to trying the following IIS performance tuning options:

1. Use IIS Compression.
2. Enable at least static caching, and enable dynamic caching if it makes sense to do so.
3. Tune your Aspnet.config files and machine.config files and web.config connection strings for your application(s).

Checking your connection strings in web.config

By default, the max pool size for connection strings in a web.config file is 100, so try specifying something higher, like "Max Pool Size=200; Min Pool Size=10; Connect Timeout=45;".

Example:

<add name="SiteSqlServer" connectionString="Server=mydomain.com;Initial Catalog=myDB;User ID=DB;Password=myDB;Max Pool Size=100;Min Pool Size=10;Connect Timeout=45;" providerName="System.Data.SqlClient" />

Checking your settings in Aspnet.config

Location: C:\Windows\Microsoft.NET\Framework\v2.0.50727 and C:\Windows\Microsoft.NET\Framework64\v2.0.50727

Example:

<system.web>
    <applicationPool maxConcurrentRequestsPerCPU="5000" <!-- Default is 12 -->
             maxConcurrentThreadsPerCPU="0" <!-- Default is 0 -->
             requestQueueLimit="5000" <!-- Default is 5000 -->/>
</system.web>

Checking your settings in machine.config

Location: C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG and C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

processModel

Example:

<processModel 
   enable="true"
   requestQueueLimit="5000" <!-- Adjust if necessary. Default 5000 -->
   restartQueueLimit="10"  <!-- Adjust if necessary. Default 10 -->
   memoryLimit="60" <!-- Adjust if necessary. Lower for memory leaks. -->
   maxWorkerThreads="100" <!-- Default 20 -->
   maxIoThreads="100" <!-- Default 20 -->
   minWorkerThreads="40" <!-- Default 1 -->
   minIoThreads="30" <!-- Default 1 -->
/>

connectionManagement

Example:

<system.net>
  <connectionManagement>
    <add address="*" maxconnection="100" <!-- Default is 2 --> />
  </connectionManagement>
</system.net>

Windows and linux have two different page/swap strategies.

Linux

Linux wants to avoid using swap space at all, and waits until the last possible moment. If you see a large amount of swap in linux, your system likely is or was in trouble. This strategy is good for minimizing overall disk i/o, which is the slowest part of your system, but weaker for systems with alternating periods of light and heavy load (and honestly, that's most of us). The times when your load is already heavy will now be burdened by the "extra" disk i/o, or, put another way, you need to design your server builds with an eye to having enough ram you don't swap even during the highest expected load times.

Windows

Windows wants to treat memory as a mere cache of the page file. Your real memory is always on disk, but it will read/write from the "cache" first if it can. This strategy is good for evening out your load over time; when the system gets busy and needs to swap pages, the current page is already on disk and half the work is already done. This approach made huge sense back when Windows was young, 32MB (forget GB) was still a lot of RAM, and the frequent need to use swap space was a given. Even today this is good for work-loads that alternate between light and busy loads, as it helps spread the disk i/o out more evenly over time.

Modern Windows versions have additional optimizations — such as SuperFetch — to pre-load and prepare memory pages on disk and in RAM when the load is otherwise light, to help avoid the need for extra disk writes when loading a program for the first time. All of this means you can design your system to only need enough RAM for something less than the highest expected load, so you can still have at least acceptable performance all the time, with reduced costs.

Convergence

This concept of measuring or predicting load in a test environment first and then allocating production resources when the load is known is a relatively recent development in system building, made possible, or at least practical, in part with the advent of virtual and then cloud servers. Depending on your load, you may even design the system such that it never needs to swap at all. In these cases, Windows does allow you to turn off paging and behave more like a linux system. However, you have to be careful; if your system design requires more memory than expected you can get yourself into trouble this way.

On the other hand, modern linux kernels are more willing to swap to disk opportunistically than they once were. So the difference in memory management strategies between the two systems is still present, but now less distinct than it used to be. Both systems have their merits, and each watches the other to see which advances they can copy.