Partager via

Overlapped Recycling And SharePoint: Memory Based Recycling

  • Article

I have already mentioned the values for Maximum Memory used and Maximum Virtual Memory we recommended in our recent whitepaper in previous posts but I want to speak on them directly for a minute. Let’s start by saying that there is no lack of controversy on what the proper values are for these settings. There are teams within Microsoft that believe that the Maximum Memory Used setting should never exceed 800MB and that the Maximum Virtual Memory setting should never exceed 1500MB. These are great conservative numbers and if you can service your required user load without constantly recycling the worker process while using them, then I would say that you should use them. They represent a “safe harbor” setting. Using these settings you will probably never see SharePoint logging allocation failures in your ULS or Application Event Logs.

Unfortunately, many of our customers are trying to get the last bit of life out of their 32-bit servers while moving from the less resource intensive world of SPS2003 and WSSv2 to the more feature rich and resource intensive world of MOSS and WSSv3. This means that they are often willing to take a slightly more aggressive approach to memory management to buy time until their hardware leases expire or until they have completed testing on their new 64-bit hardware. So, while there may be some theoretical or anecdotal controversy around using the 1000MB/1700MB values, we have used them successfully in some very memory intensive environments and I feel comfortable that they will work for the vast majority of customers running SharePoint.

It is possible that in some environments you may even be able to push the “Maximum memory used” setting of 1000MB a little further but I would strongly recommend that you test it thoroughly and aggressively monitor your ULS logs and Application Event logs for memory related errors to ensure that you are not causing problems for your users. While I’m on the subject, with all of the setting levels mentioned above I would recommend that you regularly peruse your Application Event Logs and ULS logs to ensure that your system is healthy and stable, this is just good administrative practice.

There is a also a hidden value in configuring the Maximum Memory Used setting. 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 Maximum Memory Used setting to determine how aggressively it governs the cache. In a nutshell, if you don’t set the Maximum Memory Used value, the ASP.NET Cache will assume that when your process reaches 60% of physical memory or 800MB of Private Bytes that we are running low on memory. It will then begin to induce garbage collections in the managed heap to free some memory. 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.

 

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.

 

In his post Thomas mentions a very important code change 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. In the right scenarios, configuring the Maximum Memory Used setting and this hot fix can provide dramatic improvements in performance.

Comments