7

We are considering a SharePoint 2010 configuration where we deploy separate app pools/web applications for each business unit in our company. We would have 10 app pool/web app instances total in that configuration.

Microsoft's current guidance is for 10 app pools max per server, but with the caveat that it is really limited by server memory. Our WFEs current have 8GB RAM each.

How much RAM would be required to host 10 app pools (or more allowing for growth)? Is 8GB enough? Are there any thumbrules for estimating RAM usage per app pool? What other problems would I likely encounter?

Improve this question
0

5 Answers 5

Reset to default
5

Application Pools generally consume around 100-200MB minimum depending on various configuration aspects. 10 Application Pools would therefore be around 1-2GB+.

Improve this answer
3
  • I should mention that these numbers are minimums. application Pools when a server is under load grow to be much larger. The number above a guideline related to minimum memory capacity.
    – Chris Beckett
    Jun 24, 2011 at 15:50
  • Thanks @chris - these numbers are helpful. Have you deployed anything this large? If so, what other problems might I encounter besides memory depletion?
    – Wade Henderson
    Jun 24, 2011 at 17:49
  • Accepting this response as the best of the submitted answers. All contain excellent information and guidance, and have been very helpful. Thanks for the discussion!
    – Wade Henderson
    Jun 30, 2011 at 14:40
5

If you are limited by Memory, you can share the same App Pool between several Web applications. This will allow you to save some memory. Sharing AppPools will allow you to pool that "base" memory per app pool.

The total amount of requiered RAM cannot be dertermined by just the number of WebApps, but is also affected by many other factors.

A valid reason to move one WebApp to its own Application pool would be if it does "not behave well" (Memory leaks, AppPool crashes ect.) That would allow you to apply some resource contrainsts on that application pool.

Improve this answer
3
  • Thanks @Heiko. For isolation and internal governance reasons, we are planning 1 web app per each app pool for our deployment. Based on @chris 's reply below, do you agree with his baseline number for minimum RAM? That will at least give us a starting point.
    – Wade Henderson
    Jun 24, 2011 at 17:47
  • The total amount is hard to predict. It depends on a lot of things, like cache, number of sites, clean code... ect. Forcing a recycle is common, but i dont see it as a good practice. Discussing 1 day on how much RAN you need (with a consultant) costs way more than upgrading a server to 16 GB. Under 64 bit a stable app pool can consume 2 GB easy. I would pool the webapps and only allow exceptions their own. What reasons you have for seperating each webapp into its own pool?
    – Heiko Hatzfeld_MSFT
    Jun 25, 2011 at 20:32
  • We want to separate them out for governance and management reasons. We would like to be able to easily identify which groups are consuming the most resources. Since app pool is tied directly to IIS worker process, separate app pools will make this very clear.
    – Wade Henderson
    Jun 30, 2011 at 14:33
3

The thing to remember is that on x64 systems, an app pool can consume a lot of memory, if unchecked, 1GB+. On x86 systems, ASP.NET is capped at 900MB by default. Setting a memory cap is useful, but will cause the app pool to recycle if the app tries to go over it, basically bringing your app down for a few seconds. If bad code (Undisposed SPSite objects etc.) is deployed to a web app, the resulting memory leaks could cause this to happen regularly (and I'm talking every hour or less for high load apps).

So the main thing is to make sure the code running in those apps behaves the way it should :-D!

Improve this answer
2

Be careful here - Chris is correct in that 200MB is an absolute minimum amount of RAM that an app pool might use. On the flip side, if you had say 5 very busy app pools you could quite conceivably hit 24GB + RAM usage. I wrote a blog on app pools on this a while back which goes into a little more detail (which includes some input from Steve Smith, MVP).

This isn't a question we can really answer without fully understanding your requirements. It very much depends on how many servers you have, concurrent usage, timer job scheduling etc.

As far as the number of Web applications you create is concerned, you generally want to keep this number as low as possible. As a hosted solution provider we normally try and stay below 5.

Remember that site collections are your unit of scale, not Web apps.

Improve this answer
1

There is another way to play this... - given you require this high level of separation for business reasons - you could go one step further and - (effectively) give each SP - web application its own Windows - server

SP - farm - by design - will deploy - all 10 SP - web applications onto each - SP - front-end - web server (assuming you have more than one) - and as you require - each SP - web application to run in - a separate IIS - application pool - you will have 10 .NET - virtual machines (CLR) - all running multiple threads and - all competing for the same processor / memory resources

Instead of using "normal" network load balancer approach - you map web-address of each SP - web application - to a specific Windows - server (IP - address)

You could also do something like use 4 Windows - servers 5 SP - web applications on one load-balanced pair 5 SP - web applications on another load-balanced pair

Each server will in any case have all 10 SP - web applications - deployed and configured to run in its own IIS - application pool - but - unless a SP - web application actually recieves a HTTP - request - the .NET - virtual machine (CLR) is not "started"

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.