w3wp.exe hogs memory

On a Small Business Server 2011 installation a whole number of w3wp.exe processes appear to be using a disproportional lot of memory. The SBS out-of-the-box installations comes with a total of 7 sites and 20 ASP.NET application pools (Sharepoint, Exchange, WSUS and SBS-specific stuff like Remote Web Workplace).

The resulting dozen of w3wp.exe processes tends to consume more than 4 GB of the server's memory over time with the peak application pool being the one belonging to WSUS with around 800 MB in the working set. Manually recycling the application pools through the IIS MMC helps temporarily reduce the memory usage (the w3wp.exe processes shrink back to 10 MB, some of them regrowing quickly), but obviously is not something an admin wants to do all day. I was unable to find any recommendations on automatic recycling of the SBS-preinstalled application pools, so I am somewhat reluctant to "just do it" on production systems.

My research on the net on how to limit this only threw up a number of posts stating that w3wp memory consumption would not hurt but benefit performance as memory would be "freed when needed by other applications". The trouble is that it does not work out:

• for one, an SBS is a multi-role server, one of the roles (the major one) being CIFS network storage which immensely benefits from filesystem caching which again relies on memory being "free" as in "not used by other processes in any way" - ASP.NET application pools which are hardly ever seeing users and eating memory are counterproductive
• another thing is that I still have to see substantial decrease of the w3wp instances memory consumption upon memory shortage - what I see is a minor decrease by significantly less than 100 mb and excessive swapping instead - again hurting performance

I hardly ever administer IIS or ASP.NET apps, so any ideas on how to effectively trim the memory requirements for the application pools are welcome.

Solution 1:

Welcome to the wonderful world of SBS. Recommended requirements for RAM = 10GB... and it REQUIRES a minimum of 8gb. (according to Microsoft.) for a good reason. It's not a fine-tuned well-oiled machine... it's very sloppy, bloated, and has everything under the sun bundled together. The more RAM you can throw at that box... the better. Unfortunately, you're limited to 32gb max. Which imho... is silly.

Solution 2:

This is what I ended up doing:

setting the server application cache for the .NET AppPools to a low value (5 MB) by setting the privateBytesLimit parameter in the web.config at %WINDIR%\Microsoft.NET\Framework\<version>\Config as suggested in this answer:

    <configuration>
      <system.web>
         <caching>
           <cache privateBytesLimit="5242880" privateBytesPollTime="00:01:00" />
         </caching>
      </system.web>
    </configuration>

This helped reduce the memory usage to somewhat more than 1 GB with the default pool recycling settings.

Apparently, using the "server" type of garbage collector (<gcServer = "true">) can lead to significant memory consumption as well, but as it seems, <gcServer> is set to false by default.

Solution 3:

If you suspect that the resulting memory consumption is a problem due to a software defect, you can use the Microsoft DebugDiag 1.2 to create a full memory dump and analyze the dump for common issues. If you think there may be a memory issue, you need to enable leak tracking by selecting the "Monitor for Leaks" option and let it run for a while before creating/analyzing the dump.

DebugDiag 1.2 Download
https://www.microsoft.com/download/en/details.aspx?id=26798

Solution 4:

You don't need a separate app pool for every app, just those that are unreliable or you wish to give priority to. Many can share (keeping different .net versions separate). You can then more realistically limit the memory an app pool will use. There should be no need to repeatedly recycle pools more than once a day.

Also, there is only so much memory that can be freed up in this manner. While some of it will be cache, each app needs a certain amount of working memory which is highly dependent on the specific web app. Trying to restrict this too much is going to bring things to a grinding halt.

The problem really is that SBS tries to do too much at once, you need to look at what you actually use and shut off what you don't.

But to be honest for just 11 users, where is the rest of the memory going? Exchange and SQL for light use certainly don't need more than 12Gb!