Application Pools and Memory Best Practices for SharePoint Front Ends

Have you ever gotten an out of memory exception on your SharePoint web front ends and wondered why? Or how to prevent it? I started getting this error periodically, and through such experiences have drawn several best practices for managing the memory on your SharePoint web front ends.

Best Practices:

1. Don't have too many Application Pools

Each application pool (app pool) running on the server will consume around 100MB of memory, at a minimum. So, if you have 10 app pools that is 1GB of useless memory! Plus, app pools are like SQL server in some respects, one of which is that they both like to build up a lot of information in cache. If you have many app pools, you're getting the same files/data cached several times over because each app pool has its own cache. This of course isn't memory friendly. I usually run 3-5 app pool on each front end. Five app pools are what I try to limit myself to. I typically call them as follows:

- SharePoint Sites
- ASP.NET 1.0 Sites
- ASP.NET 2.0 Sites
- Sensitive Application 1 (generic name for some application in the company)
- Sensitive Application 2

With this paradigm, you are bucketing all your non-critical sites into 3 categories, SharePoint, ASP 1.0, and ASP 2.0 sites. The reason for 1.0 & 2.0 is that the different versions of ASP.NET cannot be in the same app pool or things won't behave as desired.

Thereafter, you can create an app pool for each critical application that you feel needs to be isolated (App. 1 & 2) from other non-critical application.

2. Set Memory Capacities on Each App Pool

The main avenue of confidence to not running out of memory and getting rid of the out of memory exception is to set memory caps on each app pool. This will limit how much information they can store in cache. If you take the 5 app pools I mentioned above, this is how I would allocate memory if I had 4GB of memory available:

- SharePoint Sites (1GB – SharePoint needs as much cache as possible to help with performance)
- ASP 1.0 Sites (500MB)
- ASP 2.0 Sites (500MB)
- Sensitive Application 1 (500MB)
- Sensitive Application 2 (500MB)

With this configuration, Internet Information Services (IIS) will consume at max 3GB of memory, leaving 1GB for the operating system. Obviously if you don't have any ASP.NET 1.0 applications, or other critical applications, you would allocate that memory where it made sense, like taking the 500MB from ASP 1.0 and increasing SharePoint Sites to 1.5GB.

NOTEWORTHY DEPENDANCY: In order to allocate 3GB on a 32bit OS for your ASP.NET worker processes, you MUST change the user mode space on the server from 2GB to 3GB. The reason for this is 32bit operating systems have a cap on their virtual memory that is 4GB. 2GB of this is dedicated to the OS. However, by making a change to the boot.ini file, you can increase that maximum to 3GB. Check out this KB article on how to do this. This is why 64bit operating systems are a really important upgrade to get onto ASAP. With 32bit, you'll never have more than 3GB of memory! 64bit is practically limitless in its capacity. Back to my example of the five app pools, if you don't increase the 2GB cap and you still allocate your app pools up to 3GB like what was recommended, you'll actually INCREASE your risk of getting out of memory exceptions (or memory exceeded exceptions) because IIS thinks that memory should be available, but it won't be. Only allocate 2GB on 32bit operating systems if you don't increase the boot.ini file to 3GB!

Here's how to set the capacity on an app pool:

In IIS, expand the Application Pools folder, and right click the app pool you want to set a cap on, and click Properties:

On the recycling tab, click the check box to specify the maximum virtual memory to 1GB (1000MB):

Click OK ("used memory" is physical memory, which is less important because ASP runs in virtual memory. Virtual memory is physical memory plus disk, or swapped memory).

3. For serious traffic, plant a garden

Now if you have followed the best practice and your web front ends are all on 64 bit operating systems with 8GB of memory or more (8GB is a MUST for medium to large SharePoint environments!!!), and you're sites are expected to handle thousands of requests and hour - you need a web garden. The basic point to a garden is to make more W3WP worker process available so IIS can handle more requests and faster. If you only have one worker process, and that process is currently unavailable because it is busy, all other requests will get queued up. By creating a garden, you are setting up additional worker process that will be available to simultaneously handle more requests.

NOTE: You MUST have setup best practice #2 before you create a garden, or you will most certainly start running out of memory!! More W3WP processes sitting around waiting for requests, means more stuff is being cached! Also, you'll pretty much want to be on a 64bit OS too, because 2GB of memory will get chewed up pretty quick if you have multiple worker processes.

So, back to our 5 app pools, this is how I would configure them on an x64 OS with 8GB of memory:

- SharePoint Sites (3 W3WP processes, at 1.5GB a piece, totaling 4.5GB)
- ASP 1.0 Sites (1 W3WP process at 500MB)
- ASP 2.0 Sites (1 W3WP process at 500MB)
- Sensitive Application 1 (1 W3WP process at 500MB)
- Sensitive Application 2 (1 W3WP process at 500MB)

This would leave 1.5GB for the operating system. However, the model above is making the assumption that the most of the traffic on the site is going to the SharePoint sites. Again, the point of a garden is putting the additional W3WP process where they make sense, which is onto the app pool(s) that receive the most traffic. That may not be your SharePoint sites, but on a SharePoint web front end, it is most likely the case.

Here's how to setup a garden:

Again, click Properties on the app pool you want to add more worker processes too, and click on the performance tab. At the bottom, specify how many processes you want: