Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

Is there a recommended average CPU threshold in running Windows boxes based on experience in other shops?

Background: We are running with Windows Server 2003 32-bit OS. Servers are handling a major enterprise-level web application suite with a high frequency of small transactions mixed in with much larger transactions - overall average is 13ms.

Our average overall CPU utilization of the Windows servers are ~60% during prime-shift. And we question at what level does the Windows OS begin to shimmy on the CPU scheduling road?


share|improve this question
given the limited amount of information 60% ute you should be ok! Should is the key word, the latency of 13ms suggests you may have other issues that are not cpu bound! – tony roth Jun 16 '10 at 17:46
Tony, you are right about the other issues in the 13ms figure. We have several hops from end to end that we cannot address due to technical requirements. These hops are costly. – Mike Taylor Jun 16 '10 at 20:15
up vote 0 down vote accepted

OK there's a few things you need to watch out for here.

Firstly is redundancy / fallover. If you have 5 machines running at 90% capacity, and one of the machines fails, then the other 4 machines have to pick up the slack ... whoops ... that takes them over 100% capacity and you will likely start to have a cascade failure on your hands.

Secondly, IF you're running multiple processes, then remember that the OS takes compute cycles to SWITCH processes too. This means that if the system load gets too high, the system can start spending too long loading and suspending tasks for execution, and less and less time actually executing the processes.

Thirdly, if you're running MS SQL server, for goodness sake configure it correctly or get someone to do it for you. MS SQL server will suck up all available RAM for cache and can bog down the machine if you don't limit its RAM usage. I have had clients who were complaining about RAM usage on a server, doubled the RAM, and noticed no performance gain because MSSQL server sucked it all up again!

Hope those help :-)

share|improve this answer
Why is using RAM something bad? I never understood that... free memory is unused memory = mostly bad right? ^^ – Oskar Duveborn Jun 16 '10 at 17:56
It's only bad if you've decided to run SQL and anything else on the same server. SQL will take most of the RAM whether or not it needs it, and not give any back to the OS for other processes that need it. If you're only running SQL, this is great. If you're running other things, then you will either be unhappy, or you need to limit the max memory SQL Server will grab. In this way, SQL is different from most other applications, because it is different from most other applications. – mfinni Jun 16 '10 at 18:08
Xsdfsdfsdf, your're spot on with your 3rd paragraph discussing OS scheduling. We are running multiple processes (~600/sec). But, with that being said...what have you found to be your cutoff when additional work causes system degredation due to Windows OS scheduling? 60%,80%, or 90% busy? – Mike Taylor Jun 16 '10 at 20:23
I think it depends on your workload. If you're not starved of IO or RAM, and you're not doing too much context-switching (so you know the process you care about is getting most of the CPU), you should get the same performance from 20% CPU all the way into the 90s. – mfinni Jun 17 '10 at 1:32
I'm accepting this as my answer. Including the following notes: Looks like 75% is the rule of thumb for the CPU threshold based on this article: Below 75% and queue length grows linearly. 75% and above it grows exponentially. Another article adopts the 80% mark and points out response times will increase 5 times the service time since the queue is on avg 4 long. Article (read the comments): Thanks for everyone's help. – Mike Taylor Jun 17 '10 at 3:59

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.