VeeshanVault

Im having an odd issue with a server and Im at the end of my rope with it, as is the case with most production servers a reimage is out of the question.

The machine is a Dell r710 dual quads with 4gb ram in raid 5 running 2003 R2. The issue is the machine is a slug, just about every action takes a few seconds to process; from accessing a document in a share to simply RDP'ing to the machine and opening the start menu. This server houses a mission critical database and the lag time has forced timeouts in SQL several times a day. Perfmon reports nothing out of the ordinary, no spikes of any sort, no disk I/O problems, PERC drivers are up to date, no errors in the log files. Any suggestions?

p.s. It is a slug with or without SQL running.

AV perhaps?
We have to exclude the data dirs and mdf/ldf files because we were getting time out issues. I know you said without SQL running as well - but worth a shot.

With our R710's I remember when we were getting them for our VM boxes there was a lot of confusion about memory type - only in triplets unless X condition was met - Get slower memory when Y condition was met (I believe this was when you exceed 96G memory) - and of the 3 groupings that you can place memory in, if you're using specific types of memory, you want to use different slots that are optimized for the speed/type.

Sorry it's vague, all i remember was it was a PITA ordering these things in a functional configuration.


CPU/memory utilization outrageous or anything noteworthy? You mentioned perfmon (which counters?) and disk I/O is ok.

There's process explorer aaaaand something else in the sysinternals pack that can help you - http://technet.microsoft.com/en-us/sysi ... 42062.aspx

pyrella wrote:AV perhaps?
We have to exclude the data dirs and mdf/ldf files because we were getting time out issues. I know you said without SQL running as well - but worth a shot.

With our R710's I remember when we were getting them for our VM boxes there was a lot of confusion about memory type - only in triplets unless X condition was met - Get slower memory when Y condition was met (I believe this was when you exceed 96G memory) - and of the 3 groupings that you can place memory in, if you're using specific types of memory, you want to use different slots that are optimized for the speed/type.

Sorry it's vague, all i remember was it was a PITA ordering these things in a functional configuration.


CPU/memory utilization outrageous or anything noteworthy? You mentioned perfmon (which counters?) and disk I/O is ok.

There's process explorer aaaaand something else in the sysinternals pack that can help you - http://technet.microsoft.com/en-us/sysi ... 42062.aspx

I turned off SEP for a few hours during my initial troubleshooting with no joy. CPU doesnt get above 26% even during peak times of day, memory never goes more then 40% utilization. For perfmon I watched everything from Disk I/O to page faults and even average disk que length but nothing, as was predicted for the load the server is about 80% underutilized and thats what makes this issue so frustrating.

Memory configuration however is something I didnt consider, Im going to go back to my quote and see exactly what it was I ordered for the memory configuration. I have 7 other R710s and 2 of them area identical hardware configuration to this one although, this is the only one running 2003 R2 Standard, the others are running Enterprise.

x86/64?

pyrella wrote:x86/64?

x86 on the one having issues, 64 on all the others..hmmm...

We have a random issue with the IT tracking/inventory/worthless legacy crap software spawning dozens of instances of the same process on servers and some workstations too. It doesn't show up on the perf monitor, because they technically don't use that much memory or any processor cycles, but they seem to run as very high priority, and either inspect every command before it runs or something like that. We made a batch file that kills them, and the machines affected by this instantly become more responsive.

Ran into something similar once, the slowdown turned out to be a name resolution issue. Their name service was borked and everything that was called by name took forever as it had to wait for the timeout.