Many IT professionals who purchase Diskeeper originally begin evaluating the product after they experience issue they determine stem from badly fragmented disks. It starts out that something breaks, or simply slows to a crawl (e.g. SQL Server). As they investigate they use systems management and monitoring tools to narrow down the source of the issue. This is especially true on servers, where split seconds can add up to thousands of dollars of lost revenue.

There are a number of technical articles that delve into specifics that can be used to diagnose this situation. One such paper on SQL Server is Troubleshooting Performance Problems in SQL Server 2005. In the section I/O Bottlenecks, it describes a number of counters to look for that can help pin point the source of the poor performance.

I’ve also written about these counters in white papers and noted how many are indicators of fragmentation.

As I mentioned, we see customers regularly trial and purchase Diskeeper as they find the software resolves these discovered bottlenecks. For example, we recently had two cases where a SQL Administrator discovered Average Disk Sec/Read was very high on their database servers.

Per the Microsoft article, the following is a gauge of what Average Disk Sec/Read mean: Less than 10ms = very good Between 10-20ms = okay Between 20-50ms = slow, needs attention Greater than 50ms = serious I/O bottleneck So when I mean they found a high count for Average Disk Sec/Read, I’m understating the issue as they were seeing 200ms and 300ms delays. That is well into the “serious” part of the scale. As you would expect, the article provides possible solutions to address that I/O bottleneck. However, one solution not explicitly stated is to defragment. The two IT Professionals that found those really high wait counts ran Diskeeper and, using just the software alone, brought the Average Disk Sec/Read back to around 15 and 30ms. That’s a tremendous improvement in performance!

Employing some/all of the other appropriate solutions now that the volumes are kept fragment-free will bring these SQL servers into optimal ranges. It isn’t uncommon for defragmentation to be left off a list of solutions, as it is still unknown to many.

A clue that you should evaluate a defragmenter is when you read or hear a recommendation to increase I/O bandwidth -such as adding more disks. Example: your SAN vendor tells you to add another controller or array. If there is substantial fragmentation, Diskeeper will typically provide better results, as it actually fixes the issue rather than masking it, and it’s a whole lot cheaper.