01.13Sharepoint Memory Considerations

A recent lesson learned in regards to Sharepoint infrastructure.  There is only so far a 32 bit OS, with 4 GB’s of ram can go.  Let’s take a deeper look as to why.

Sharepoint utilizes virtual memory to run.   On a 32 bit OS, remember that any given application can only run in a single 4 GB memory space.  Steve Sheppard (works on Sharepoint at Microsoft) had a nice white paper (and blog post) talking about how this limit can affect your Sharepoint environment.  The bottom line, if you start experiencing traffic on the rise, be watchful… you could run out of virtual memory and start locking worker processes (the process that utilized by IIS’s Application Pools), and can even crash them.  Obviously that means downtime for your end user (yuck).

In that same blog post he mentions that you can also setup a series of SIMPLE (and highly effective) performance counters (basic Windows 2000/2003) on the server and gauge how close you are to this sort of a scenario.  What I ended up doing was I setup two counter logs (because the scales are so different) with the following counters:

Performance Counter One:

  • % Usage (Paging File)
    Obviously how badly your paging file (virutal memory) is being taxed… a great indication in this regards.
  • Requests Current (ASP.NET)
    The current number of requests, including those that are queued, currently executing, or waiting to be written to the client.  Under the ASP.NET process model, when this counter exceeds the requestQueueLimit defined in the processModel configuration section, ASP.NET will begin rejecting requests.
  • Requests Queued (ASP.NET)
    The number of requests waiting to be processed.   
  • Request Execution Time (ASP.NET)
    The number of milliseconds that it took to execute the most recent request

Performance Counter Two:

  • Working Set (Process)
    It shows how much RAM is required so that the actively used virtual memory for all processes is in RAM.
  • Pages Output/Sec (Memory)
    This shows how many virtual memory pages were written to the pagefile to free RAM page frames for other purposes each second.  This is the best counter to monitor if you suspect that paging is your performance bottleneck
  • Pool Nonpaged Bytes (Memory)
    This measures the size, in bytes, of the non-paged pool. This is an area of system memory for objects that cannot be written to disk but instead must remain in physical memory as long as they are allocated. There is a possible memory leak if the value is greater than 175MB (or 100MB with the /3GB switch). A typical Event ID 2019 is recorded in the system event log.
  • Pool Paged Bytes (Memory)
    This measures the size, in bytes, of the paged pool. This is an area of system memory used for objects that can be written to disk when they are not being used. There may be a memory leak if this value is greater than 250MB (or 170MB with the /3GB switch). A typical Event ID 2020 is recorded in the system event log.
  • System Code Total Bytes  (Memory)
  • Virtual Bytes (Process)
    Indicates the current size (in bytes) of the allocated (reserved and committed) virtual memory.
  • Thread Count (Process)
    Shows the number of threads currently active in the current process.

The one that you want to keep an eye on the most to springboard into the information that the other counters shows, is the REQUESTS CURRENT.  That will be your first indication of usage traffic.  Consider the following diagram:

Notice how immediately you notice a steep increase in activity… for a typical 32 bit OS with 4 GBs of RAM, this is pretty much bringing the server to a crawl and is nearly about to crash.   In this scenario, if you look at mainly the Working Set, and Private Bytes you should notice a spike in those as well that coorelate with the Requests Current.  All the other stats can help you narrow down things in a general sense and then go from there.

Make the switch to 64 bit Sharepoint as soon as possible.

The true bottom line, you can really solve alot of your major problems of this nature by simply getting off your 32 bit system, and onto 64 bit.  You might as well since it’s only a matter of time before everything is anyway.  But just a simple illustration of it’s benefits (credit goes to my co-worker Jason on this one, it’s about the simplest way I have heard so far to explain it), if you punch in your (scientific) calculator 2^32 you will notice that a 32 bit system is only capable of 4.2 billion unique locations (or 4 GB’s of memory hehe) that it can utilize for memory management.  But if you type 2^64 you will notice the phenominal increase of 1 Terabyte (at least as of Windows Server 2003)!  Man, now that is something crazy.

Anyway… this is just a super simple suggestion on how to begin your own troubleshooting, but perhaps this gives you a nice entry point into similiar issues you might be encountering in regards to memory managment with Sharepoint.  I highly suggest Steve Sheppard’s very helpful article on this subject which goes into both the Virtual and Physical implications of your current server configuration.

References:

Filed under: Sharepoint 2007, Sharepoint 2010, Windows, , , , , ,

Leave a Reply

« »