Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Please help refine a discussion going on in our shop.

Consider the following scenario. There is a Microsoft VPC running several apps and services (Windows 2003 server). The server has two or three critical roles. Every so often, CPU utilization goes to 100% on a sustained basis. One of the culprits in this is a legacy application, for which the only real solution, at this time, is to restart the service. After this, CPU utilization returns to something reasonable (on average, 60-80%). However, less often, when the server is at 100% CPU, another service appears to be using the lion's share, a security application that parses logs. Our operations team's impulse is to restart that as well when the CPU becomes pegged. Our security team points out that this is pointless, as this service is running at BelowNormal priority, so effectively it is not depriving any other process of CPU. Security argues that the 100% CPU usage in those cases should really not be considered a critical condition. If a BelowNormal priority process is using most of the CPU, then there is actually no CPU deficit at all. Operations, on the other hand, is skeptical that 100% CPU utilization could really be a condition without adverse consequences, and doesn't want to ignore it. Who is right? Is Security right that it's nothing to worry about or Operations that we ought to do something?

share|improve this question
You're not worried that the service in question is so broken that every once in a while it spikes too 100% and has to be bounced on a critical server? Even if it only spiked to a sustained 80% if the usage can't be explained it's broke. – Jim B Jan 30 '10 at 0:18
You're right, it's a deeply unhappy server all around. But our short term focus is on what to do to keep it running... – Eldergriffon Jan 30 '10 at 21:12
up vote 7 down vote accepted

In cases like this, you need to go beyond task manager and looking at % CPU usage. That does not tell you if something is adversely affecting performance. For a case like this, the next step would be to use Performance Monitor to view System\Processor Queue Length. This tells you if processes are waiting for the CPU to become idle possibly affecting performance. This is similar to what you see in the top or load commands in Unix.

This article has a good description of the performance metrics to look at when troubleshooting these issues. It was originally for NT4, but still applies to newer versions.

Here is a more recent article from the Windows Performance Team talking about how to hunt down performance issues with the CPU.

share|improve this answer
100% CPU utilization is neither good nor bad - It's a poor arbiter of performance in my experience. Processor Queue Length ("load average" in UNIX-land) is a better, though still imperfect indicator. – voretaq7 Jan 29 '10 at 23:29
Thanks, this definitely helps focus the discussion. – Eldergriffon Jan 30 '10 at 21:15
@Eldergriffon - I added a link which may help you further than what I had posted before. – Doug Luxem Feb 3 '10 at 14:57

How are you measuring the CPU%? If this is a virtual machine, Perfmon may not always deliver accurate results. Is there a possibility the spike is related to activity on the host machine? Virus scans, auto-updaters, lots of other things could affect a guest vm and make it look like 100% cpu from the VM's perspective, it may be 100% of a much smaller CPU slice.

share|improve this answer
Measuring with perfmon. I don't know if we checked host activity, good point. – Eldergriffon Jan 30 '10 at 21:16

Processing huge amounts of log data is something that SHOULD peg the CPU. If it doesn't then your process is likely IO bound. As long as the meter goes back down when processing is complete (and the machine is reasonably responsive to it's other duties when pegged) it's nothing to worry about.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.