Overlapped Recycling And SharePoint: What Are The 64-bit Settings?

We strongly recommend that our customers move to 64-bit servers for MOSS and WSSv3 unless there is some significant reason that prevents it. It is also worth noting that according to our recent documentation this will definitely be the last version of SharePoint to run on 32-bit hardware. This brings up the question of whether or not you need to configure overlapped recycling on 64-bit servers.

While we have quite a few customers already on 64-bit servers I have not seen a lot of problems that would be addressed by these settings but I have seen a couple. This tells me that there is still value in configuring these settings on 64-bit servers. Unfortunately, I don’t have any solid data to make recommendations on what those settings should be.

That means the best I can offer is some thought on how I would figure it out. I would start by enabling a scheduled recycle each day that happens about 30 minutes before my first users start work. This makes good sense as I consider a daily recycle to be good housekeeping. As mentioned in a previous post, recycling the worker process cleans out fragmentation and results in a more orderly workspace.

Next, I would get Performance Monitor data for my servers for a period of two weeks. These two weeks would ideally contain a few days of my highest user loads. It is also important that during these two weeks that I’m not already experiencing problems like crashes or memory allocation related errors in the ULS or Application Event Logs.

While I can’t tell you exactly what days are in your business are the most intensive I can give an example to guide you. Many companies function on a monthly cycle where their peak loads occur at the end of each month. In this type of business I would gather my data for the last week of the current month and the first week on the next month. This would probably give me a solid representation of my heaviest loads and my lightest loads.

In my scenario I’m going to guess 30% growth over the max I see in my Performance Monitor data is about the most to I want to allow before I recycle my worker process. I will be using that number in the calculations below.

Once I have my data I would then determine the maximum size that the worker process ever reached over that two week period in terms of Process/Private Bytes and Process/Virtual Bytes. I would also gather the Memory/Available MBytes value from those same times where I saw the maximum values.

Once I had these values I would first determine if I have enough free physical memory to enable overlapped recycling. To determine this I would compare the maximum Private Bytes value to the available MBytes value and if Available MBytes was not at least equal to ((Private Bytes value * 1.3)+300MB) I would not enable overlapped recycling until I had added more physical memory to the system.

Assuming I have enough free physical memory I would then use those maximum observed values plus my 30% growth factor to come up with the settings for the “Maximum Memory Used” and “Maximum Virtual Bytes” recycle settings. Here is an example:

Maximum Observed Private Bytes	2000MB
Maximum Observed Virtual Bytes	4000MB

Using these numbers I would configure the IIS Application Pool using the following settings:

Maximum Memory Used Value	2600MB
Maximum Virtual Bytes Value	5200MB

UPDATE 6/19/2008 

I thought it was worth coming back to this post and updating it. As of this date we have not seen any significant problem in this area with customers running on 64-bit platforms. Most of the customers I am aware of on 64-bit platforms are not using memory based recycling settings. I do want to say that I would still reccomend a scheduled nightly recycle because it will help reduce any possiblity of problems caused by fragmentation.