Sitefinity Memory Usage

We commonly get questions about the memory usage of various Sitefinity instances so I decided to share some information about the fundamental forces in play there. I will mostly talk about the memory usage on startup as it is the initial impression and causes a lot of confusion although the behaviour is valid for all .NET applications and usage patterns.

 A common question is why do we get X Mb of memory (where X > 500) usage for a simple Sitefinity site on the very first request. The truth is that Sitefinity can allocate around 1 GB on start if the server on which it is running could afford this. It is usually achieved on servers with more than 15GB of free memory. We can also achieve a setup where Sitefinity startup takes as little as 70Mbs on machines with very little available memory and with all Garbage Collector settings set for memory consumption optimizations at the expense of performance (the startup in question was tens of times slower). The amount of memory allocated by Sitefinity is governed by the .NET Garbage Collector and it is responsible for finding the balance between faster execution (less garbage collections) and less memory consumption (more garbage collections). Sitefinity is provoking a lot of memory allocations on start because a lot functionality is executed on start – things we do not normally think of are happening like database model initialization, configurations reads, modules initialization, providers initialization, routes registrations, MVC controllers registrations, caching etc… No memory is leaking in those functionalities in the sense that some memory is allocated and not released after it is no longer needed but a lot memory is temporary allocated which schedules a lot of work for the Garbage Collector. From there on the Garbage Collector implementation decides how much memory to allocate before stopping the execution to clean unused memory.

This combined with the fact that by default the Garbage Collector settings for websites does not give memory back to the operating system once it has allocated a given amount is quite often the reason for larger memory allocations of applications with little traffic.

This also explains a commonly discussed fact that Sitefinity uses a lot less memory when running in a 32 bit application pool (32 bit process). This is simply because the maximum allocatable memory for such processes is much less than what is available for 64 bit applications which creates a higher memory pressure - forcing the Garbage Collector to allocate less memory. This is again sacrificing some performance although the feedback that we are getting suggest that a more aggressive garbage collector and the subsequent less memory usage is preferred from some clients. 

The good news is that Microsoft continues to improve the Garbage Collectors implementation and gives new ways to control its behaviour with every major release. You can read the recommended environment settings explaining more about some of ways to control the CG behaviour here: http://www.sitefinity.com/documentation/documentationarticles/recommended-environment-settings-for-sitefinity