Overview of Performance Monitoring
Overview of Performance Monitoring |
|
Computers that provide shared resources to users of a network are called servers. This section describes the relationship between a the workload of a server and its resource utilization. This section also covers establishing a baseline for a server, identifying emerging problems, and upgrading.
Some servers are characterized by the workload they support, as indicated in Table 5.9. Servers supporting these workloads can have specific resource requirements. These requirements and how to monitor them with performance monitoring tools are described later in this chapter.
Table 5.9 Objects to Monitor Based on Server Workload
| Server workload | Heaviest resource usage | Objects to monitor |
|---|---|---|
| Application servers | Memory and processor | Cache, Memory, Processor, and System |
| Servers used for backups | Processor and network | System, Server, Processor, and Network Segment |
| Database servers | Disks and processor | PhysicalDisk, LogicalDisk, Processor, and System
If using Microsoft® SQL Server™, see the product documentation for information about installed performance objects. |
| Domain controllers | Memory, processor, network, and disk | Memory, Processor, System, Network Segment, Network Interface, protocol counters (TCP, UDP, ICMP, IP, NBT Connection, NetBEUI, NetBEUI Resource, NWLink IPX, NWLink NetBIOS, NWLink SPX), PhysicalDisk, and LogicalDisk
The NWLink object counters report zero values for frame-related data. For Active Directory, also monitor the NTDS and Site Server LDAP Service objects; for Windows 2000 servers, monitor the Browser object. As applicable, monitor DNS or WINS objects. |
| File and print servers | Memory, disk, and network components | Memory, Network Segment, PhysicalDisk, and LogicalDisk
For print servers, use the Print Queue object for monitoring queue activity. |
| Mail/messaging servers | Processor, disk, and memory | Memory, Cache, Processor, System, PhysicalDisk, and LogicalDisk
If using Microsoft Exchange, see the product documentation for information about installed performance objects. |
| Web servers | Disk, cache, and network components | Cache, Network Segment, PhysicalDisk, and LogicalDisk |
Tip
As a general recommendation, servers with major roles should be dedicated to a single purpose rather than shared among multiple purposes. For example, do not have domain servers or database servers do double duty as application or file and print servers because these secondary activities can impede the ability of the server to handle its primary workload.
As a service runs, it makes specific demands on system resources. In addition to the monitoring resource requirements defined by the computer's workload, you can obtain information about the services using performance data made available through the services. Many services running under Windows 2000 Server supply performance counters that can be used to measure service activity and resource utilization. Monitoring these counters provides data you can use to determine how well your server is functioning.
In addition to the standard counters described in "Overview of Performance Monitoring," you can use the System object counters to obtain information of interest on server computers. For example, you might want to examine the values for System\System Up Time. If this value is consistently low, it might indicate frequent failures, meaning that the server remains up only for a short time.
Monitor the performance of your server at the busiest times of day as well as when it is idle or when activity levels are low. Consider the number of concurrent users as well as the number of inactive connections during the times you are monitoring because the server expends resources tracking inactive as well as active connections. After collecting and reviewing this data, you can set a baseline for the performance of your server. This baseline can be used as a reference point for determining when performance problems exist and for projecting future resource requirements. When data consistently falls outside of the baseline ranges, consider it a signal that the performance of your server is changing—either because the demand is increasing or a bottleneck is developing. You will then want to monitor activity more closely to determine whether your server needs tuning or upgrading.
When you become aware of changes in performance that result in values outside your baseline, monitor the system counters representing the disk, memory, processor, and network components along with the Processor\% Processor Time counter for the services that you are running to see if there is a correlation between service activity and resource usage. If so, you might need to tune the service.
Note
Unless you are testing a computer's startup performance, wait until the startup process has concluded before monitoring system performance. Otherwise, you might mistake the high utilization values characteristic of process startup for the process's typical load.
In general, you will want to monitor a server from a different computer so as to minimize the impact of the testing process on the computer being tested. For more information about the advantages and disadvantages of remote versus local monitoring, see "Monitoring Remote Computers" earlier in this chapter.
The chapters "Analyzing Processor Activity," "Evaluating Memory and Cache Usage," and "Examining and Tuning Disk Performance" in this book provide information about tuning and planning for upgrades for hardware resources such as memory, processors, or disks when counter values indicate that these are being strained by your workload. In addition, the chapter "Measuring Multiprocessor System Activity" addresses the special considerations for obtaining optimal performance from scaled systems and discusses the benefits of server clustering and load balancing.
The capacity of a server depends on many variables, including the number of work units (such as client requests), the amount of time required for each unit, and the corresponding resource utilization. Because of the many variables of an individual server implementation, it is extremely difficult to arrive at a perfect formula for gauging the capacity of your server.