| Legal Information |
|
The baseline you develop establishes the typical counter values you expect to see when your system performs satisfactorily. However, you need guidelines to help you interpret the counter values and eliminate false or misleading data that might cause you to set target values inappropriately. You need to identify and investigate bottlenecks to analyse your results and take action.
When you collect and evaluate data to establish a valid performance baseline, you should:
You need to watch for values that are unusually large for one instance and not another when you are monitoring processes that have the same name. This can occur because System Monitor sometimes misrepresents data for separate instances of processes of the same name by reporting the combined values of the instances as the value of a single instance. Tracking processes by process identifier can help you solve this problem.
When you are monitoring several threads and one of them stops, the data for one thread might appear to be reported for another. This is because of the way threads are numbered. If you begin monitoring and have three threads_numbered 0, 1, and 2_and one of them stops, then all remaining threads are sequenced again. This means the original thread 0 no longer exists and the original thread 1 is renamed 0.
As a result, data for the stopped thread 0 can be reported along with data for the running thread number 1 because old thread number 1 is now old thread number 0. To solve this problem, you can include the thread identifiers for the process in your log or display. You can use the Thread/Thread ID counter for this purpose.
You do not need to place too much importance on occasional spikes in data. These spikes might be due to the startup of a process and, if so, they are not an accurate reflection of counter values for that process over time. The effect of spikes can remain over time when using counters that average.
When you monitor performance over an extended period of time, you need to use graphs. Reports and histograms show only last values and averages, and they might not give an accurate picture of values.>/p>
Unless you specifically want to include startup events in your baseline, you must exclude them because they are temporary high values that tend to skew overall performance results.
Zero values or missing data can impede your ability to establish a meaningful baseline. You should investigate the source of these issues and obtain the missing data, if possible, before you attempt to establish a baseline.
Deviations from your baseline provide the best indicator of performance problems. However, as a secondary reference, the table, describes recommended thresholds for object counters. You can use this table to help identify when a performance problem is developing on your system.
| Resource | Object\Counter | Recommended Threshold | Comments |
| Hard disk | LogicalDisk\ % Free Space | 15 percent | None |
| Hard disk | LogicalDisk\ % Disk Time | 90 percent | None |
| Hard disk | PhysicalDisk\ Disk Reads/sec, PhysicalDisk\ Disk Writes/sec | Depends on manufacturer's specification | Check the specified transfer rate for your hard disks to verify that this rate does not exceed the specifications. Some SCSI disks can handle 50 to 70 I/O operations per second. |
| Hard disk | PhysicalDisk\ Current Disk Queue Length | Number of spindles plus 2 | This is an instantaneous counter; observe its value over several intervals. For an average over time, use PhysicalDisk\ Avg. Disk Queue Length. |
| Memory | Memory\ Available Bytes | Less than 4 MB | Research memory usage and add memory if needed. |
| Memory | Memory\ Pages/sec | 20 | Research paging activity. |
| Network | Network Segment\ % Net Utilisation | Depends on type of network | You must determine the threshold based on the type of network you use. For example, for Ethernet networks, 30 percent is the recommended threshold. |
| Paging File | Paging File\ % Usage | More than 70 percent | Find the process that is using a high percentage of processor time. Upgrade to a faster processor or install an additional processor. |
| Processor | Processor\Interrupts/sec | Depends on processor | A dramatic increase in this counter value without a corresponding increase in system activity indicates a hardware problem. Identify the network adapter or hard disk controller card causing the interrupts. You might need to install an additional adapter or controller card. For current CPUs, use a threshold of 1,500 interrupts per second. |
| Server | Server\ Bytes Total/sec | If the sum of bytes total/sec for all servers is roughly equal to the maximum transfer rates of your network, you might need to segment the network. | |
| Server | Server\ Work Item Shortages | 3 | If the value reaches this threshold, consider tuning the InitWorkItems or MaxWorkItems entries in the registry (in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\lanmanserver\ Parameters). |
| Server | Server Work Queues\ Queue Length | 4 | If the value reaches this threshold, there might be a processor bottleneck. This is an instantaneous counter; observe its value over several intervals. |
| Multiple Processors | System\ Processor Queue Length | 2 | This is an instantaneous counter; observe its value over several intervals. |
Caution Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editor bypasses the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customise Windows 2000, you must use the programs in Control Panel or MMC wherever possible.
Investigating performance problems should always start with monitoring the system before looking at individual components. In precise terms, a bottleneck exists if a particular component's limitation keeps the entire system from performing quickly. Therefore, even if one or more components in your system are heavily used, if other components or the system as a whole show no adverse effects, then there is no bottleneck.
Factors that cause bottlenecks include the number of requests for service, the frequency at which requests occur, and the duration of each request. As long as these factors are perfectly synchronised, queues do not develop and bottlenecks do not occur. The device with the smallest throughput is typically the primary source of a bottleneck.
It is difficult to detect multiple bottlenecks in a system. You might spend several days testing and resetting to identify and eliminate a bottleneck, only to find that another bottleneck appears in its place. Only thorough and patient testing of all elements can ensure that you have found all of the problems.
It is not unusual to trace a performance problem to multiple sources. Poor response time on a workstation is most likely the result of memory and processor problems, while servers are more susceptible to hard disk and network problems.
Problems in one component might be the result, rather than the cause, of problems in another component. For example, when memory is scarce, the system moves pages of code and data between hard disks and physical memory. The memory shortage becomes evident from increased hard disk and processor use, but the problem is the lack of memory, not the processor or hard disk.
| Search Knowledge Base | Feedback |