Overlapped Recycling And SharePoint: A Hidden Benefit

There is a hidden value in configuring the overlapped recycling values. I was lucky enough to gain the collaboration of Thomas Marquardt on a particularly nasty performance case and he let me in on this little secret. Well, it’s not really a secret it’s just so obscure that if you don’t know about it, and where to research it, then it might as well be.

 

The secret is this, the ASP.NET Cache references the value entered into the “memory used” setting to govern how aggressively it tries to reduce the size of the cache. In a nutshell, if you don’t set the “memory used” value, the ASP.NET Cache will assume that when your process reaches 800MB of Private Bytes that we are running out of memory and it will begin to induce garbage collections in the managed heap to free up some space. The further past 800MB you go the more aggressive it gets. This will show up in a Performance Monitor trace as a sharp increase in the .NET Memory/% time in GC and .NET Memory/# Induced GC counters for your worker process as memory pressure increases.

 

Note:

In his post Thomas mentions a very important code fix that was released as a hot fix prior to .NET 2.0 SP1 and included in .NET 2.0 SP1. It was created to adjust how aggressively the ASP.NET Cache responds to low memory conditions. Anyone running SharePoint should have the hot fix or the service pack installed. The kb for the hot fix is: KB93876.

 

I won’t try to restate the details on how this works here because it is complicated and I would probably get it wrong. I also won’t try to simplify it because Thomas has already done a very good job of mapping it out, you may just have to read it a few times to really understand it completely. You can find Thomas’ words here.