Would You “Schedule” Fast Computer Performance?

Posted by B. Boyers on Wednesday, November 21, 2007 - 01:41 am:

Share | Create New | Reply | Edit

Picture this: an email message shoots out to all computer users at a company that says something like, “peak system performance will occur between 12 noon and 4 PM Monday through Thursday.” It would of course create havoc—as many users as possible would jump onto the system during those times to get any resource-intensive work done. Server processes would be scheduled to run in these windows. Perhaps even backups would happen then so they could be completed quickly.

This is, of course, a ridiculous scenario. Nobody would do that. And the basic reason (among many) is that IT staffs aim to achieve peak system performance as close to constantly as possible. It doesn’t happen by itself; there is the constant addition of newer, faster hardware, tweaking of network traffic, processes and other resources, as well as shifting of processes to free up resources. But nonetheless consistent peak performance is the goal.

So given that, why would a site “schedule” defragmentation? That, too, may seem like a ridiculous question—until you take a close look at today’s computing environment and IT personnel demands.

Today’s technology has become increasingly complex. Developments such as NAS and virtualization, along with sophisticated CRM and database applications, keep a datacenter working more than full time. Add to that the increasing need to keep servers up and running 24X7, and you can see that time IT time taken to figure out and schedule effective defragmentation is an ever-increasing burden on already overtaxed personnel.

Additionally, any defragmentation solution that slows down performance and affects network traffic while it runs is, in many environments, intolerable. Time windows in which a scheduled defragmenter can run have become increasingly small and in some quarters have disappeared altogether.

Scheduled defragmentation is also being outpaced by today’s enormous disk capacities, growing file sizes, and intense fragmentation rates. More capacity, bigger files and increased traffic means, as one might guess, more fragmentation. In between defragmentation runs, fragmentation continues to increase and impact performance. And in some cases, fragmentation is not even being affected by the defragmenter.

Just as you would never “schedule” peak performance, so too you should never have to schedule defragmentation. It should be an invisible, automatic procedure, requiring no human intervention. While it runs, it should not impact performance at all. Fortunately, defragmentation solutions which meet these criteria are now available.