Since last couple of months, I’ve been assigned to check our live server’s health and was collecting performance counters analyzing them and reading lot of things on web. It opened so many questions in my mind related to ASP.NET Memory and frankly no document was capable enough to answer my questions. But today, I just got good articles by Jesper Jørgensen, which are really worth to read:
http://jesperen.wordpress.com/2007/05/23/understanding-aspnet-memory/
http://jesperen.wordpress.com/2007/12/10/aspnet-memory-limit/
above two links applies to 32 bit, and following links applies to 64 bit.
http://jesperen.wordpress.com/2007/12/10/aspnet-memory-limit-part-2/
Highlights:
Applies to 32 bit
– In a standard setup your worker process always have 2GB Virtual memory available (no matter if you have 1, 2 or 4GB physical memory in the machine). If you use 1.5GB memory in your application but your machine only has 1GB physical memory, some of it is just swapped to disk. Thats why it is virtual memory. This also means that if you are running out of (virtual) memory it doesn’t help to add more physical memory.
So why am I limited to 2GB virtual memory?: Well, a 32bit operating system (OS) is only able to address 4GB memory with these 32 bits. In a standard setup 2 of these are reserved for the OS, and the remaining 2 reserved for applications like ASP.Net.
A common error in memory heavy applications is the OutOfMemory Exception (OOM). It happens when the framework is unable to allocate enough virtual memory to run a piece of code. This is a bad thing because they can be thrown almost anywhere in your code, making it hard to predict the outcome. What happens is that the framework lost a battle against custom code about access to the limited 2GB memory.
So how many megabytes should be allowed for the workerprocess?: Microsoft recommends to “set the memory limit to the smaller of 60% of physical RAM or 800 MB“.
Applies to 64 bit
In v1.1, we also supported WS03. WS03 used a different process model (w3wp). This process model gets its private bytes limit from IIS configuration (“Maximum Used Memory” on Recycling tab of Application Pool properties in IIS Manager), not the aforementioned . Unfortunately, this limit had no default (it was not set by default). So if the application used the ASP.NET cache, we would never drop entries and eventually you would start seeing OutOfMemoryExceptions. These are non-recoverable, and required human intervention since the process would typically stay up and serve responses with a nicely formatted OutOfMemoryException error page from that point forward.
Sitecore basics! 