Having spent a significant amount of time spinning up raw servers recently, I applied the v4 .NET framework patch, and on the restart the server instance became un-useable as the CPU jumped to 100% and stayed pegged. I eventually got the task manager up, sorted for CPU load and found mscorsvw.exe 'camping' the processor.
Because it was a server instance, I could use my machine to google the offending beast. In short order I found the following from the Microsoft Dev world.
http://blogs.msdn.com/b/davidnotario/archive/2005/04/27/412838.aspxThe post is old, but I believe the construct holds that .NET is busy compiling assemblies once anything with .NET has changed. It is quite dis-concerting to have a fresh server go non-responsive (the polite form of bat-sh*t crazy), and my guess is that v4 of .NET is bigger, 'badder', and eats longer and harder. FYI - for those using the Updox connector, it uses .NET as well.
I will say that since those first episodes, the server seems fine, but it has 5.0.29 on it atm because it is an "Upgrade" instance. There is a 6.0.9 instance on the same chassis that has been up, in use, and trouble-free for the last 10 days.
I don't understand the argument for 8 Cores, as all of our instances are single processor; I'd add memory before processors because AC doesn't appear heavily threaded - like say an Apache or Tomcat server.
I will say that we tend to run 'lean' servers, and turn off everything that isn't essential to the operation of a practice. So no Exchange or Sharepoint for example; for the typical practice a hosted service [i.e. hosted exchange or Google Apps] is less work and headache.
The .NET upgrade itself is not that daunting especially if you know that the machine needs to sit and chew once it comes back up.
If you are In-extremis and want to reach out you are welcome to private message me.
