Investigating Disk Paging

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 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 using the following steps and associated counters:

1. To confirm hard page faulting use the following Memory and Process counters:

   • Memory\Pages/sec

   • Process ( All_processes ) \Working Set

   • Memory\Pages Input/sec

   • Memory\Pages Output/sec

2. To understand the impact of page faulting on the disk, compare the number of reads and read bytes measured by the following counters:

   • Memory\Page Reads/sec

   • PhysicalDisk\Disk Reads/sec

   • PhysicalDisk\Avg. Disk Read Bytes/sec

Confirming Hard Page Faults

To confirm hard page faults, examine the hard page fault rate using Memory \ Pages/sec and the working sets of active processes using Process( process_name )\Working Set, as described in "Investigating Memory Shortages." 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 processes' working sets enables you to correlate a given application's 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 laptop 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 client computers. Paging activity tends to reach a steady state on server computers; therefore, longer-term monitoring is appropriate.

Note

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 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 if 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 sufficient to hurt system performance. See Figure 6.5 for an example of page faulting.

Note

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 6.5 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 Performance" 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 disk's 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 with 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 disk's overall work is occupied with reading pages from memory. To do this, compare page reads to 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 could 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 or 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 could in turn be causing a disk bottleneck. To see if this activity is reaching a rate high enough to cause poor disk performance, see your disk manufacturer's 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 Performance" in this book.

Figure 6.6 illustrates disk activity associated with paging activity when memory is low.

Figure 6.6 Disk and Paging Activity When Memory Is Low