I have been having many issues with this- and until I read where to disable - I was not really aware these were creating the problem.  My hoster -  Arvixe thought this was a way to solve the App Pool time out issue (where the application stops and you get a 503 error:

 It appears that DNN is taking more than the configured 90 seconds to stop when a recycle of the application pool is triggered.
The only other relevant error found in the server logs relates to forms authentication and is probably because of the above.

I have configured your application pool shutdown timer up to 120 seconds, and set the application pool recycle interval to 24 hours specifically for your site.
If this resolves or at least mitigates the trouble there, we can duplicate the settings to your other affected sites.

DNN has gotten so large lately (the application size) that I would not be surprised if it is just taking more than 90 seconds to stop, even under light load.

 Question:  Is the shutdown timer an issue for the App pools or is it the scheduler or is it both?

i have taken the scheduled tasks - all of them off-  however the logic built into this escapes me- perhaps there could be a primer on what is really needed for which tasks and how frequent  -so small sites and low users do not  run into this issue.

 I have approx. 400mb alotment so how often is a refresh really required/  Point me in the right direction or to a post or documentation that explains this in more detail (thinking other users would also benefit from such info).

Thanks,
Mike

I ran into a high CPU problem on our production server last week. (DNN version 6.2.5). The problem did not manifest itself on our test-server, nor in our development environments. There also seemed to be no relation between the number of requests and the probability of the problem occurring.

I made dumps using DebugDiag and the (32 bit version of) taskmanager. Analyses of the dumps with WinDbg  showed all of the runaway threads busy with an Insert call on a generic dictionary in the UserController.GetCachedUser method.

This method indeed gets a dictionary from the cache and sets a value on it. The dictionary is a common generic dictionary, not thread-safe. However the object is shared among threads through the cache, and thus a thread-safe dictionary should be used.

I have fixed this by changing line 242 in method UserController.GetUserLookupDictionary so that the CBO.GetCachedObject overload with the saveInDictionary parameter is used, having set the saveInDictionary  parameter to true.

So far, the high CPU problem has not returned in the past 24 hours. Before the fix, the problem would manifest itself one or more times per hour. The fix does not seam to have had any adverse effects on performance or otherwise.