1Gb ought to be enough for anybody!

If your EPiServer site consumes more than 1Gb, and you can’t explain in measured detail why, you probably have a problem.

I’m often called in when EPiServer sites have problems under load in live production settings. Problems that can’t be reproduced in the development or staging environments. Problems that are not resolved despite upgrading the server memory, running web farms, installing more CPUs or implementing more caching.

Some of the problems concern unchecked memory consumption with forced recycles as a result. Others concerns hangs and crashes, but this post is about high memory situations.

A small-to-medium site should run perfectly fine in 300 – 500Mb, a very large one should do well in 1Gb. I’ve yet to see a site that really requires significantly more than 1Gb.

This has become even a larger issue with the advent of 64-bit Windows and .NET – now servers often have 16Gb or more memory, and few consider why a single EPiServer site with perhaps 100,000 pages would need that much memory.

Do the math! Let’s say the site uses 10Gb of memory, and let’s say your site has 100,000 pages whereof 10,000 is the ‘working set’, i.e. frequently requested directly or indirectly. That means the site is using 1Mb / page! Even with both internal and output caching that’s simply not reasonable except in a few very special cases.

There are many possible reasons for excessive memory usage, but they are not true memory leaks. It’s just a question of your code holding references to more instances of objects than you may be aware of. Some reasons include attaching instance event handlers to static events, excessive string duplication (do consider using String.Intern() for commonly used strings such as URLs and parts thereof), page instance methods adding data to static collections and unawareness of implications of keeping references around to system objects (they are larger than you may realize). Generally speaking, almost all memory problems come from adding object references to static collections either in per URL code or even worse, per request code.

If you do have a site with more than 500 – 700Mb of memory usage, and you don’t really know why, check it! When I say that you should know why, I mean that you should have measured the memory and know what it’s used for – not just assume for example that a caching scheme is responsible.

Measure it! But how? Take a memory dump and use WinDbg from Debugging Tools for Windows. The standard place to start is http://blogs.msdn.com/b/tess/ . Load the dump and SOS.dll and then do:

!dumpheap –stat

!dumpheap –strings

You’re sure to find food for thought…