Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a dedicated server that we use to stage websites (our test server). The performance of the server has become really bad and we regularly have to restart it. When performance is poor I have checked task manager for the processes and memory but everything looks OK.

We use a content management system and it is always when using the admin section of this CMS that we notice the performance degrade which makes me think it may have something to do with DB calls the CMS is making.

Does this sound viable? Any other sggestions of how I can go about testing this?

Thanks in advance...

share|improve this question

3 Answers 3

Does this sound viable?

Yes.

Any other sggestions of how I can go about testing this?

Performance check. Note that performance is not CPU only. If you think the db isthe issue, it may be IO bound - disc latency / activity percetnage will skyrocket in this case. Check disc performance counters. Especially if you are IO buond, CPU will be low as the CPU basically does not serve the processes because it is waitnig for IO to finish.

Getting more busy, typically, databases require significant IO budgets, which means quite some discs. I have a database here that uses 6 10k RPM discs now, and soon gets upgraded to 8 - ONLY for the data. A typical cheap dedicated server often has really crappy IO budgets - slow large end user discs, few of them, do not make a fast subsystem. This works quite well in some scenarios, but at the end it could be overloaded.

share|improve this answer

As TomTom said this is almost certainly an indication that your system is IO bound not CPU bound. The root cause might just be the increased load DB behind your CMS or it might be something else but in any case PerfMon has some useful counters to look at that can tell you for definite if the disk subsystem is the cause.

\LogicalDisk\Avg. Disk Sec/Read and \LogicalDisk\Avg. Disk Sec/Write
These are your basic latency numbers for read and write IO operations, the lower the better. Anytime these numbers exceed around 15ms the performance of the server will be noticeably poor.

\LogicalDisk\Disk Bytes/Sec and \LogicalDisk\Disk Reads/Sec and This will tell you overall disk throughput. These rates may be saturating the maximum capacity of the disk subsystem either due to throughput alone or because you've hit an IOPs limit for your read\write pattern. It can be hard to deduce anything significant from these unless you are 100% confident that you have a predictable IO pattern though. Thhere's no really useful way to give any specific number to watch for here but if you are seeing 50-100MBytes/sec or more off a single SATA disk that would be about as good as you could expect to see. Faster server disks (10k, 15K, SSD) can exceed that and SAN attached storage can deliver pretty much whatever you want provided you pay enough. With small random IO (typical of DB operations) this number will always be low and doesn't tell you much.

\LogicalDisk\Disk Writes/Sec, \LogicalDisk\Disk Reads/Sec and \LogicalDisk\Disk Transfers/sec These will tell you the number of discrete IO operation per second and the Read\Write ratio. Spinning disks are fairly limited in this regard - 7.2K SATA disks can sustain around 70-80 IO per second, 10K disks push that up into the 100-150 range, 15K will be 200+. SSD's will be an order of magnitude or two higher. RAID groups increase this fairly linearly for reads but Writes will incur a penalty of between 2 and 5. A 3 drive RAID 5 pack (with a write penalty of 4) supports about 25% fewer write IO's than a single drive for example.

If this number tends to increase while latency is increasing into dangerous territory (ie > 15ms) it is a strong indication that your disks are hitting an IOPs limit, regardless of the specific numbers reported.

\LogicalDisk\Split IO/sec This will tell you how many IO requests result in multiple operations and will give you a sense of how much fragmentation is impacting IO activity.

PhysicalDisk : Current Disk Queue Length and PhysicalDisk : Avg. Disk Queue Length. This tells you how many outstanding IO's are waiting to be completed at the physical disk level. If this is 2 or higher on a single disk, or exceeds the number of disks in the RAID group that the disk is built from then you may be pushing more IO's into the disk than it can complete in a timely fashion. There are scenarios where this doesn't matter too much but it will be a real killer for systems that require low latency disk IO (databases where memory caching can't cover the weakness of the disks). The first is an instantaneous reading so only worry about it if it is consistently high or changes in line with the %disk time counter. If the Avg. Disk Queue Length is too high then you definitely have a problem.

PhysicalDisk : % Disk Time % Disk time tells you how busy the disk is. As it approaches 100% you are going to struggle to get the system to do anything else that depends on that disk as all additional IO will tend to be queued. Even numbers significantly below 100% can indicate an issue and if this is high, or rising, and Current Disk Queue length is high that is a clear indication of an IO load that exceeds the capacity of the disks. This number is actually calculated in a weird way and as a result might not be all that useful in analysing RAID performance.

This Technet Blog Article goes into a lot more depth on some of these counters and some scenarios where you can use these to identify the problem and establish how to fix it.

share|improve this answer

Is it worth considering configuring your web app pool to recycle worker processes frequently?

share|improve this answer

Your Answer

 
discard

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.