As part of
hosting of DotNetNuke sites, I often take a look at the processor and memory usage of the various processes running on our servers using Task Manager. Prior to recent changes though, I didn't really have any way to really know which of my sites was really having the biggest impact as all I could really see was a list of the worker processes (w3wp.exe) associated with the app pools. The UserName for each w3wp.exe process was Network Service. I did notice that one of the worker processes, averaged around 14% of the overall utilization while most of them averaged 0% percent with an occasional bump up to 1% or 2%. I figured this must have been one of the busier sites we hosted. I was wrong...
A couple weeks ago, I noticed that our website monitoring service was reporting random occasional brief outages with some of our sites. This was bad. The server was showing some pretty serious usage (50% CPU utilization for extended periods) and the two issues seemed related. So, I began thinking we needed to hurry up the process of scaling up a new server so we could spread out the workload better.
While I worked on getting additional stuff (RAID controller, more RAM, harddrives) ordered for the new server, I spent some time working on what I thought was a short term fix to improve the server performance until we could get the new server in place. So, I worked on consolidating some of the less used sites onto some shared application pools to free up memory and converted some of the application pools .NET 4.0 hoping that might help some.
In this process, I kept seeing that it was one worker process that seemed to be hogging the CPU cycles. I grew frustrated enough with not knowing which worker process in the task manager correlated to which Application Pool, something that had bugged me for years but not enough to actually resolve, that I finally decided to find a solution. So I Googled something-or-other and eventually found out that (here's the important take away from this blog), in Windows 2008 (not needed in R2, R2 sets this by default), if you go into the Advanced Settings for an Application Pool and change the Identity from "Network Service" to "Application Pool Identity", it will still use the security settings of Network Service, but will show the UserName in the Task Manager as the App Pool name.
Doing this allowed me to see that it wasn't at all one of the most heavily trafficked sites that was using all the CPU cycles. In fact it was one of the least trafficked. With this knowledge, I was able to explore further and eventually found out that Active Forum's Mail Connector was making over 5 million POP3 connections per day. And, that prior to upgrading Active Forums and DNN to newer versions, MailConnector was only making 3 million connection per day. It was the extra 2 million connections per day that had pushed the server over the edge. After resolving this MailConnector race issue, MailConnector was now only making 23,000 Pop3 connections per day, the server was back to humming along happily at an average CPU utilization of 14%, and the urgency for ramping up the new server was less urgent.
Changing the Identity of your Application Pool to "App Pool Identity" is also very useful when debugging an already running website in Visual Studio as when you do an "Attach to Process" it's clear which process you need to attach to.
Happy Coding!