Welcome to the Diskeeper Blog

This blog will provide technical data and insights into performance and reliability issues surrounding file system performance. We hope to cover all topics related to system performance including defrag whether you are running SANs, NAS, workstations, servers, SSD's or other systems. We will provide interesting anecdotes, white papers, and related story topics on defragmentation and other performance issues. The blog is intended to be personal rather than a formal Diskeeper website. You will read personal viewpoints on our products and where we see the industry and our company going. We are excited to have this opportunity to share our product knowledge and insight, and hope this information helps you. We encourage your comments and look forward to you following this blog.

Optimizing Your SQL Server's I/O Performance

by Michael 29. October 2007 19:32
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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

General

Comments are closed

RecentComments

Comment RSS

Calendar

<<  March 2010  >>
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar