w3wp.exe using too much memory and resources
w3wp.exe using too much memory and resources
Posted on Oct 1, 2009 by Paul WhiteIf you are here, the chances are you have already gone through a few pots of coffee, and lost a few hairs over trying to figure out why your W3WP.exe process is consuming so much memory. The solution is actually very simple, but first a little background information.
What is the W3WP.exe process?
The W3WP.exe is the IIS worker process, that handles requests, maintain sessions, viewstate, and the cache. Its been around Since IIS 6 on Windows Server 2003, and is still found as part of IIS 7.5 with Server 2008 R2. On a properly configured, and programmed website the W3WP.exe can usually stay under 100 Megs. If you are running a 64bit OS it could be a little larger. The actual size of the W3WP.exe will be determined by how much traffic your website gets, and how many pages it serves. The 100 Meg figure is just an estimate from my own experiences. Application Pools with multiple websites can easily go over this figure, so don't use it some magic number. But if you are running a website that has relatively low traffic ( under 20K impressions daily ), and your W3WP.exe is taking up 100+ MB of Memory, then you might want to make some changes.
Why do I care if W3WP.exe is large?
Lets say that you have a website running on a shared hosting account. As your site grows, it will start to experience bottle necks from the limited resources it has access to on the shared box. Remember the average shared server is running on average 300 websites. You site is constantly fighting other sites for CPU time and resources. Eventually you out grow the shared environment, and are forced to upgrade to either a VPS or a fully dedicated server. But what you don't know is your site could last much longer on the shared box or that small VPS, if you were to clean up your code.
Most popular causes of W3WP.exe using too much memory
Page Caching Dynamic Websites
Some Programmers will use Page Caching on their ASP.NET pages to improve request speeds. Even though this does work. It will quickly eat up all your memory. For Page Caching to work you would need to cache each page and every combination based on its querystring variables. For Members sites this could result in millions of different pages. A more effective way of using caching is to Cache objects that do not change, and are used throughout the website. Things like your menu bar. Or maybe the details for an event. This will reduce the number of calls to the database server, and speed up your site. Object Caching can make a huge difference on page load times, especially when you are able to cache objects that use expensive queries. If you want to learn more about how to custom manage objects in the ASP.NET cache, I wrote a few helper functions that are easily integrated into your websites.
ViewState Enabled on Labels
The ViewState is how ASP.NET keeps track of changes that have been made to Web Controls. ViewState is needed anytime you are going to do a postback, like for a submit form. But a common mistake is programmers don't disable viewstate on Label controls that are often used as place holders for long concatenated HTML strings. If you suspect your may be guilty of this all it takes is a look at the HTML source code from your web browser to confirm it. If your HTML source looks like this
with a really big view state then you need to disable the viewstate on your label controls. The Viewstate is stored in the W3WP.exe process. Its easy to see how this process can consumer so much memory when you have a view state this large and on an exponential number of web pages. The solution is to change your ASP:Label Controls from this
<asp:Label ID="mainmenu" runat="server" />to this
<asp:Label ID="mainmenu" EnableViewState="false" runat="server" />Lets face it there is no reason you need to preserve the ViewState of a Label Control. So go through all your pages and add the EnableViewState="false" attribute to all your Label Controls.
Memory Leaks
Certain objects should be cleared from memory with the Dispose() Method. These include things like BitMap Objects. Even though the ASP.NET Garbage Collection does a good job of taking out the trash, I have found that on heavily loaded systems if you don't release Bitmaps with the Dispose Method it tends to lock the file image file you were working with. This object will sit in your W3WP.exe taking up space. Even though memory leaks can be a problem, they are usually very minor. ViewState is by far the biggest Memory hog.
Unclosed Database Connections
If you use helper functions to manage your Database connections, be sure that you close the connections, when finished. Else this will waste memory on both the W3WP.exe side and the Database Server side.
Conclusion
Even though advanced programmers might feel some of this is obvious. I found it disturbing that I was unable to find more articles online involving something so important. Who knows, maybe if every programmer uses my advice, this could negatively affect the bottom line of hosting companies, who's customers won't be needing to get that dedicated server just yet. If this helped you let me know.
Readers Thoughts
I have never used sharepoint before, though it seems that most medium to large scale companies have it running. It doesn't really surprise me that Sharepoint is a memory hog. From what I have seen in the development world the server-sided technologies that require the least effort from a programmer, usually have the most chub. Most developers would aggree that Linux with apache is the most conservative on memory usage, while asp.net can start to get a little greedy especially if you don't know what you are doing. Then you have platforms like Cold Fusion that are just plan Fatties. I am still a fan of ASP.NET. If you know how to properly manage your memory and objects it can be extremely lean and fast.
MAINMENU
CATEGORIES
AUTHORS