Evaluating Memory and Cache Usage
Use memory counters that report paging activity to identify memory shortages resulting in disk bottlenecks. Start by monitoring the memory counters and working set values as you did when checking for a memory shortage in the preceding section. Confirm that hard page faults are occurring by using the Memory\Pages/sec counter.
If hard page faults are occurring, monitor disk counters to assess how the disk is behaving during paging: whether it is busy with other work or with handling page faults. Monitor disk paging by using the following steps and associated counters:
To confirm hard page faulting, use the following Memory and Process counters:
Process ( All_processes )\Working Set
To understand the impact of page faulting on the disk, compare the number of reads and read bytes measured by the following counters:
PhysicalDisk\Avg. Disk Read Bytes/sec
Confirming Hard Page Faults
To confirm hard page faults, examine boththe hard page fault rate by using Memory \ Pages/sec and the working sets of active processes by using Process( process_name )\Working Set, as described in Investigating Memory Shortages earlier in the chapter. Memory \ Pages/sec is the sum of Pages Input/sec and Pages Output/sec and reports the number of requested pages that were not immediately available in RAM and had to be read from the disk (resulting in hard page faults) or that had to be written to the disk to make room in RAM for other pages. Monitoring the working sets of processes enables you to correlate a particular applications memory usage with page faulting. When memory is in short supply, working sets are continuously trimmed and page faults are frequent.
Acceptable rates for Memory\Pages/sec range from 40 per second on older portable computers to 150 per second for the newest disk systems. Use a shorter monitoring period on client computers than on server computers (updating once per second is appropriate) because paging activity can occur in bursts on clients. Paging activity tends to reach a steady state on server computers; therefore, longer-term monitoring is appropriate.
Page Fault Monitor (Pfmon.exe), a tool on the Windows 2000 Resource Kit companion CD, lists hard and soft page faults generated by each function call in a running process. You can display the data, write it to a log file, or both. For more information, see Windows 2000 Resource Kit Tools Help (W2rktools.chm) on the Windows 2000 Resource Kit companion CD.
You can also monitor page faults and memory management data by using Trace Logs in the Performance snap-in. For more information, see Overview of Performance Monitoring in this book.
When values exceed the acceptable range for your type of disk, investigate disk activity to determine whether the faulting is causing a disk bottleneck. Memory\Pages Input/sec reflects the rate at which pages were read from the disk and thus gives you data on hard page faults. Depending on the capabilities of your disk, high values can indicate a lack of memory that is sufficient to hurt system performance. See Figure 28.4 for an example of page faulting.
You might see high levels of paging with Memory\Pages/sec when pages are read to and from noncached, memory-mapped files. When these files are used in this way, Memory\Pages/sec or Memory\Available Bytes is high but Memory\Paging File\%Usage and Memory\Cache Faults/sec are normal to low.
Figure 28.4 Paging Activity on a System with Low Memory
The other component of Memory\Pages/sec, Memory\Pages Output/sec, indicates the rate at which pages were written to the disk. Although this activity does not generate hard page faults, disk-write activity can indirectly reflect a memory shortage and indicates additional disk activity. This is because, as the Virtual Memory Manager needs to trim pages from a working set, it might find that some pages contain changed data. In this case, the changed data must be written to disk to free the pages. When memory is in ample supply, Memory\Pages Output/sec is likely to be low because there is less need to free changed pages and write that data to disk. For more information about investigating applications that generate disk-write activity, see Examining and Tuning Disk Usage in this book.
Assessing the Effect of Page Faults on the Disk
To understand the impact of page faulting on the disk, examine the number of disk operations that occur as a result of paging. If paging activity dominates your disks workload, a memory shortage is causing a disk bottleneck. Start by looking at Memory\Page Reads/sec. This counter indicates the number of read operations by the disk that were required to retrieve faulted pages. Compare the number of reads performed against the number of pages faulted to determine how many pages are retrieved per read. A high ratio of reads to faults means a large number of pages are not found in physical memory and are being demanded from the disk, creating a disk bottleneck.
Next, determine what proportion of your disks overall work is occupied with reading pages from memory. To do this, compare page reads against disk reads. If there is a correlation between the values of Memory\Page Reads/sec and PhysicalDisk\Disk Reads/sec, it is likely that paging activity makes up the majority of your disk activity and might be causing a disk bottleneck.
To see the relationship between paging and disk read operations from a different perspective, monitor the value of PhysicalDisk\Avg Disk Read Bytes/sec while you are monitoring Page Reads/sec. The Avg Disk Read Bytes/sec counter indicates the rate at which the disk is transferring data during reads. Because this is a measurement of bytes rather than of pages or of the number of reads, you need to convert to identical units. Use the following formula for this purpose: value of PhysicalDisk\Disk Read Bytes/sec 4096 (number of bytes in a page).
If the result is approximately equal to the value of Page Reads/sec, paging activity is the bulk of your disk read activity, and the memory shortage represented by heavy paging activity might in turn be causing a disk bottleneck. To see whether this activity is reaching a rate high enough to cause poor disk performance, see your disk manufacturers documentation for the number of I/O transactions per second you can expect from your disk. Disks currently available can sustain a transfer rate of 70 I/O operations per second. For more information about locating disk bottlenecks, see Examining and Tuning Disk Usage in this book.
Figure 28.5 illustrates disk activity associated with paging activity when memory is low.
Figure 28.5 Disk and Paging Activity When Memory Is Low