Establishing Utilization Trends

As your database collection grows, you can use it to spot peak activity periods. You can also use the collected data to look for problems that might be forming too slowly to be noticed during normal day-to-day activity. Depending on the data you collect and when you collect it, you can even determine the cause of the peak activity periods.

Consider, for example, the normal behavior of a large corporation. Every day, when your company employees start their workday, they boot their computers and log on to the server. If you have hundreds of employees performing this same task at almost the same time (over a 15-minute time frame, for example), your server will have a sudden jump in processor utilization, disk I/O utilization, and network bandwidth utilization. The utilization spike occurs as each user is authenticated by the server, their network connections are restored, and their logon script is processed.

Once this sudden surge of user logons is over, the utilization spike drops back to a flat line indicating normal activity is taking place. If the data you collected only included processor, 2disk, and network activity counters, you might have incorrectly concluded that this peak activity was caused by a process on the server. If the data you collected also included the logons/sec. counter, your chart would show peaks for the number of logons that would also correspond to peaks in the processor, disk, and network activity. Based on this information, you would be able to correctly conclude that the peak activity was, in turn, caused by your users logging on to the system.

The preceding example discusses a noticeable performance spike, but how can you find the performance problems that occur over a long period of time? Some problems can take months (or even longer) to show up. Well, this is where your performance database comes into play. At least once a week, you should take your new exported data and create a chart that you can print. You can place this chart next to the other charts you previously created. You can then compare these charts for any irregularities at least once a month. You can also compare charts from previous months, or even previous years. You might be surprised by what you will find. For example, consider the following scenario.

Let’s say you create a brand new server, and everything is in perfect working condition. The disk drives haven’t been used except to place the core system files on them. In addition, you’ve added the additional services and shared applications for your users, along with their home directories. When your users first access their new server, they are happy as can be with the performance. But over a long period of time, performance begins to suffer—not a lot, just a little. Then, little by little, performance degrades until not only do your users notice it, but they are screaming at you to fix it immediately.

Of course, you probably won’t know what the problem is or how to correct it. If you created a performance database, this is the time to start reviewing your results. You can either compare a month-to-month chart, or combine the raw data files and perform a comparison of several months all at once. In either case, you should be able to spot a general performance degradation in the disk I/O subsystem. You might even spot various low-memory situations. And if you captured the data, you might spot various service-specific problems (such as Exchange Server I/O degradations). This might lead you to the following conclusions:

•  You are experiencing a slow degradation of the disk I/O subsystem, because your file systems have become fragmented. Simply defragmenting with a disk utility such as Executive Software’s Diskeeper can eliminate the problem and restore the lost performance.

•  You are experiencing physical memory shortages because you have a memory leak. Some application might not be releasing memory when it has finished using it. You can determine which application with an exhaustive and in-depth look at your system process’s memory usage with the Performance Monitor. An intermediate solution might be to just reboot your server at least once a month rather than let it run continuously.

•  Your service (such as Exchange Server) degradation can be determined by running its diagnostic utilities—if it has them. Exchange Server, for example, includes EDBUTIL.EXE, which can be used to determine the amount of fragmentation in its internal database. This utility can also be used to defragment and compact the database. For your WINS and DHCP services, you can use JETPACK.EXE to compact the database. Other services have similar utilities, and it is up to you to use them.

A utilization trend is not always performance related. You might find that, by examining your collected data at the end of every two week period, your server runs perilously close to running out of disk space. Nothing has failed yet, but, if the situation does not improve, it might. If you look more closely into the collected data, you might find that this lack of free space coincides with your payroll process or a similar scheduled task that requires vast amounts of virtual memory and temporary file space. By looking for such trends, you can include the additional hardware you need to resolve the situation in your next budget. You can even prove that the additional hardware is needed with cold hard facts.

Summary

In this chapter, you learned what a performance database is and how to implement it. You learned how to use the Performance Monitor to capture data to a log file, and then export it for use with Microsoft Excel. You also learned about some of the Windows NT Server Resource Kit utilities and how they can be used to replace the Performance Monitor for data collection. Finally, you learned a bit about how to spot a utilization trend and what you can do to correct the situation.