We all get those calls from clients complaining that the network is slow at certain times of the day occasionally. We usually start by looking for errors or checking out the computer of the people complaining the most. Perhaps we even look at the applications they are running as a possible source of the problem. But sometimes, it really is the “network” that is slow, at least as users experience the network. The problem is actually that the server is bogged down and having trouble keeping up with the demands placed upon it.
Today’s modern servers are usually loaded with CPU’s and RAM. So a quick look at Windows Task Manager shows that the server isn’t busy at all. CPU and Page File use are not stressed, considering this server performs many functions in the network.
This particular server is about 5 years old. The business has grown over that time and applications have been added to the server over the years. I’m suspecting that while CPU and RAM have kept up with the company, that the disks have not. A performance study on disk performance is in order.
The subject server is an SBS 2003 server running on hardware that is about 5 years old. There are 4 hard drives configured in a RAID5. There is a RAID controller card installed in the server. This procedure is not SBS specific, it will work on any server where you suspect Disk performance problems. In addition to the SBS software suite this server also houses User Shared Folders and a Time Clock application. The subject company is in the manufacturing industry and they have about 80 employees and 45 computers.
The first thing that we need to do is setup performance monitoring to record the disk performance covering the period when users most often report that the server is slow.
To record potential Disk I/O issues I’m going to setup a Counter Log using these items:
- Physical Disk: Avg. Disk Queue Length (Less than 2)
- Physical Disk: % Disk Read Time
- Physical Disk: % Disk Write Time
- Physical Disk: % Disk Time (under 35)
I know from reading Microsoft’s information on Disk I/O testing in TechNet that a well running server should perform at certain levels for each of these. Those values are noted after the name of each counter above.
To Create and Schedule a Disk Counter Log
- Open Performance Monitor
- Expand Performance Logs and Alerts
- Right click on Counter Logs and Choose New
- Type a Name for the log file you are about to create and a location in which to save it
- Add the suggested counters shown in the list above
- Schedule the task to run for several hours covering the period when users report slowness
Let the task run for the period you specified then return to view the results.
Here’s snippet of what my results looked like.
I find the graph difficult to read, so I prefer to view a text report instead.
Now to do a bit of calculation. In order to get an accurate Ave Disk Queue length I need to divide with by the number of disks, which in the case of this server is 4.
Comparing our results with the specifications, we can see that our Ave Disk Queue Length is within tolerance, the Disk Read Time is somewhat over but our Disk Write Time is through the roof! We have a disk bottleneck.
What you decide to do with this information is entirely up to you. What I did was get curious to find out what was writing to my disks all the time. Is this legitimate business use of the server? To see the answer to that question and learn one way to determine where those disk writes of coming from see the blog post Determining Where All Of Those Disk Writes of Coming From. It will be posted soon to http://www.thirdtier.net/blog