Doesn’t Figure 6.8 look quite similar to the display shown in Figure 6.7? Notice the same basic peaks for Memory Page Faults/sec. and Process Page Faults/sec. Although, if you directly overlay the Memory Page Faults/sec. with the Process Page Faults/sec., you will notice that the Memory counter is a bit higher than the Process counter. This is because the Memory counter is a system-wide counter and includes other paging activity from other processes. The corresponding system-to-process counters are displayed in Table 6.3 to aid you in your analysis.

Of course. I knew which process was the problem, so my chart only includes the MemHog application. In order to find a real-world application problem, you should select all the Process instances except for the system processes, unless you are looking for a system-process memory leak. A couple of other Process object counters that you might find useful in your diagnosis of a memory-intensive application are:

•  Pool Non-paged Bytes—The non-paged pool is a system resource area devoted to system components. Allocations from this area cannot be paged out to disk. This is a finite resource, and if you run out of non-paged pool bytes, some system services may fail.

•  Pool Paged Bytes—The paged pool is also a system resource area devoted to system components. However, allocations from this area may be paged to disk. It is also a finite resource, and if you run out of paged pool bytes, a system service may fail.

---

TIP:  Both the Pool Non-paged Bytes and Pool Paged Bytes counters are very useful in tracking down a process that is incorrectly making system calls and using all of the available pool bytes.

---

•  Virtual Bytes Peak—This counter is the maximum size of the virtual memory address space used by the process.

•  Working Set—This counter indicates the size of an application’s working set in bytes. The working set includes pages that have been used by the threads. When memory is low, pages will be trimmed from the working set to provide additional memory for other processes. As the pages are needed, they will be pulled from main memory, if the page has not been removed or read from the paging file.

•  Working Set Peak—This counter indicates the maximum working set size in bytes.

---

TIP:  By monitoring the working set for a particular process and comparing that to the working set peak, you can determine if adding additional memory will increase the performance of the process. The idea here is to add memory until the working set and working set peak values are equal. This will provide the maximum benefit to the process. You should consider that this may prove to be an unrealistic goal if your budget is limited.

---

Finding Disk Bottlenecks

Finding disk bottlenecks is easier than finding processor or memory bottlenecks because the performance degradation is readily apparent. There are really only four performance counters to monitor for bottlenecks. These are:

•  % Disk Time—This counter is the percentage of elapsed time that the disk is servicing read or write requests. It also includes the time the disk driver is waiting in the disk queue.

•  Disk Queue Length—This counter indicates how many pending I/O requests are waiting to be serviced. If this value is greater than 2, it indicates a disk bottleneck. On a multidisk subsystem, such as a striped set or striped set with parity, a little calculating is in order to determine if a disk bottleneck is occurring. The basic formula is The Disk Queue Length–Number Of Physical Disk Drives In The MultiDisk Configuration. If this value is greater than 2, a disk bottleneck is indicated. For example, if you have a striped set with three disk drives and a queue length of five, then 5 – 3 = 2, and 2 is an acceptable value.

•  Avg. Disk Transfer/sec.—This counter is the time in seconds of the average disk transfer. However, it is not used just for this information. Rather, it is used in connection with the next counter.

•  Memory Pages/sec.—Use this counter and the previous counter in the following formula to tell you how much of your disk bandwidth is used for paging: Percent Disk Time Used For Paging = (Memory Pages/sec. * Avg. Disk Transfer/sec.) * 100.

When I perform disk diagnostics, I break my Performance Monitor charts into two different settings. I use the first three counters mentioned in the previous list plus the Memory Pages/sec. from the LogicalDisk object to determine the performance on a drive-letter basis. Then, I use the same counters from the PhysicalDisk object to determine my hardware disk performance. These counters are used in the LogicalDisk.PMW and PhysicalDisk.PMW Performance Monitor workspace files. These files include basic chart, alert, and report examples for you to use as a starting point.