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

Really weird problem here. Our main web server has started running at a snail's pace, for absolutely no reason we can discern. Even after restarting the machine, when there's no little or no ram usage and CPU usage is fluctuating between 0 and 30%, simple tasks, like opening Internet Explorer, or waiting for My Computer to open, take forever.

There are no processes hogging system resources that we can see... the machine itself is just exhibiting extremely slow behaviour. I've never seen a machine do this.

A lot of security updates had built up, so we decided to let Windows install them. When we looked through the history upon restarting, though, they had failed with error code 800706BA. I don't know if this could be related or not.

Any help in this matter would be greatly appreciated. As mentioned in the title, we're running a Windows Server 2008 R2 machine. It's also running SQL Server and IIS. It has 16GB of RAM and a decent Quad Core processor. It's also been fine until now -- and we haven't changed a thing.

Thanks for any help.

share|improve this question
Do you have a RAID controller in this machine, could you have a drive re-build going on? – Sam Feb 14 '11 at 22:18
Yes, we have a hardware RAID controller on the machine. An SAS 6/iR (if memory serves). Is there a way to see that it's up to through Windows? – Django Reinhardt Feb 14 '11 at 22:20
You say it's a SAS 6/iR? That sounds like a Dell server. Have you installed DOMSA on the server? That will let you see the status of the RAID array(s) and whether or not they're rebuilding. As far as I know, this information isn't available from within Windows itself but is available from withing the DOMSA application/web interface. – joeqwerty Feb 14 '11 at 22:34
You're right, it IS a Dell server. We don't have Dell OpenManage Server Administrator installed... but I can't seem to find a straight forward link to it, either. Hmm. – Django Reinhardt Feb 14 '11 at 22:51
I think I found it... 143MB! Wow. – Django Reinhardt Feb 14 '11 at 22:59

If you are able to temporarily decommission the machine, ensure you can boot and run torture tests appropriately. If you have any in house developers, get them to write a small threaded application to pound all CPU's. If you cannot force to 100% then look at the hardware.

If you can, use Process Explore ( to look at threads and see what resource they are waiting on.

If possible, stop services one by one and see if you can get performance to increase that way. You may be able to isolate the offending service.

share|improve this answer

The first thing I would recommend doing is installing the available updates, one by one. Time consuming, I know, but worth it. If one particular update is causing the failure, this is the best way to discern it.

A lot of updates that are released help in terms of both security, but also performance.

Also, can you open Performance Monitor, and run your CPU, your memory, and your hard drive IO? if you set it up to run for a 24 hour period after reboot, you might be able to identify something that occurs that creates the snag.

But like I said, start with updates.

share|improve this answer

Set the upper memory limit for SQL Server; it can take more than it should have, and force other things to swap.

Also see Microsoft KB articles 979149 and 976700.

For querying the PERC card for array status without doing the behemoth OMSA install, you can use the MegaCLI tools from the command line. The command syntax is awful, but it's a powerful tool. If you can't find it with Dell, look for it at LSILogic, the OEM for the HBA.

share|improve this answer
Django stated that there's little RAM usage. As you stated, SQL (if configured to do so) will allocate almost all of the available memory to itself but it will release it if needed. I've never known that to cause a performance problem, unless SQL is actually using all of the RAM that it's allocated. – joeqwerty Feb 14 '11 at 23:19
@Joe: True, but IME, RAM usage in Windows where SQL is involved, and especially with x64, is never as clear-cut as it ought to be. (Or maybe my DBAs are bad at explaining it to me.) Admittedly, my answer is a bit of a "Blow the dust out of the connector" response, but I'm hoping that DB install isn't the main content DB for the stack and can be throttled back to some benefit. – AndyN Feb 14 '11 at 23:37
Memory is most definitely NOT the problem. We have a 16GB machine, and even when 14GB+ is free, it's just as slow as ever. (Plus, we've already set the upper limit in SQL Server.) – Django Reinhardt Feb 14 '11 at 23:54

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.