JSI Tip 4792. Evaluating Memory and Cache Usage.

TechNet has published the following Resource Kit chapter:

Chapter 28 - Evaluating Memory and Cache Usage

Use the Performance console and other Microsoft® Windows® 2000 tools to assess available memory and to observe the effects of a memory shortage, a common cause of poor computer performance. Examine the effectiveness of the file system cache — an area of physical memory where recently used data read from or written to the disk is mapped for quick access. In addition, use Windows 2000 tools to investigate memory problems caused by applications that have not been optimized.

Related Information in the Resource Kit

Quick Guide to Monitoring Memory

Use this quick guide to view the topics and tasks related to monitoring memory usage in Microsoft® Windows® 2000 Professional.

Learn about memory requirements. 

Memory has such an important influence on system performance that monitoring and analyzing memory usage is one of the first steps you take when assessing your system's performance.

Verify that you have the appropriate amount of installed memory. 

A memory shortage is a significant cause of performance problems. Therefore, one of the first steps in examining memory usage is to rule out the existence of a shortage by learning both how much memory is required for the operating system and your workload and how much is available on your system.

Establish a baseline for memory usage. 

A performance baseline is the level of performance you can reliably expect during typical usage and workloads. When you have a baseline established, it becomes easier to identify when your system is experiencing performance problems, because counter levels are out of the baseline range.

Use memory counters to identify excessive paging, memory shortages, and memory leaks that slow system performance. 

Changes in memory counter values can be used to detect the presence of various performance problems. Tracking counter values both on a system-wide and a per-process basis helps you to pinpoint the cause.

Monitor how your applications use the file system cache,and learn to use the cache and memory counters to evaluate application efficiency. 

The cache and memory counters provide information about how applications running on your system make use of the file system cache. To accurately assess cache efficiency, you need to understand which counters to use and how to interpret their values.

Tune or upgrade memory resources as needed to improve performance. 

When you have determined the cause of a memory bottleneck, you can undertake steps to correct the problem by adding memory, removing unnecessary services, tuning inefficient applications, or other tuning methods.

What's New

Users of Microsoft® Windows® 98 and Microsoft® Windows NT® version 4.0 Workstation will notice a few changes in Windows 2000 with respect to memory resources and utilization. The following list provides a brief summary of the changes in features for these operating systems.

Overview of Memory Monitoring

Low memory conditions can slow the operation of applications and services on your computer and impact the performance of other resources in your system. For example, when your computer is low on memory, paging — that is, the process of moving virtual memory back and forth between physical memory and the disk — can be prolonged, resulting in more work for your disks. Because it involves reading and writing to disk, this paging activity might have to compete with whatever other disk transactions are being performed, intensifying a disk bottleneck. (A disk bottleneck occurs when disk performance decreases to the extent that it affects overall system performance.) In turn, all this work by the disk can mean the processor is used less or is doing unnecessary work, processing numerous interrupts due to repeated page faults. (Page faults occur when the system cannot locate requested code or data in the physical memory available to the requesting process.) In the end, applications and services become less responsive.

Figure 28.1 illustrates the sequence in which you conduct the monitoring process. Memory has such an important influence on system performance that monitoring and analyzing memory usage is one of the first steps you take when assessing your system's performance.

Figure 28.1 Role of Memory Monitoring in Overall Monitoring Sequence 

In the first phase of analyzing memory usage, you need to understand your current memory configuration and workload. To help you do this, use the steps in the following list:

Focus subsequent monitoring on how your system uses memory, and on identifying memory shortages or other problems, by taking the following steps:

Determining the Amount of Installed Memory

Start your monitoring efforts by knowing that you have at least the minimum amount of memory required to run Windows 2000. Windows 2000 Professional requires at least 32 megabytes (MB) of memory.

The memory recommendation for Windows 2000 Professional is based on a typical desktop configuration including a business productivity application, such as a word processor or a spreadsheet program, an e-mail application, and a Web browser.

There are a few different ways to determine the amount of memory on your computer. You can find the amount of physical memory installed on your system by clicking the Performance tab in Task Manager. Or you can find the amount of available RAM by double-clicking System in Control Panel, and then clicking the General tab.

Note You can see the memory configuration on local or remote systems by using System Information. For more information about System Information, see Windows 2000 Professional Help.

The operating system distinguishes memory usage by applications and services depending on whether the usage involves the paged or the nonpaged pool. The paged pool contains memory for objects used by applications and services that can be paged to disk; objects in the nonpaged pool cannot be paged to disk. The operating system determines the size of each pool based on the amount of physical memory present. Memory pool usage can be an important factor in evaluating memory usage by your applications. For more information about memory pools, see "Investigating User-Mode Memory Leaks" and "Investigating Kernel-Mode Memory Leaks" later in this chapter.

The file system cache, which is a subset of physical memory used for fast access to data, and the disk paging file, which supports virtual memory, influence the amount of memory used by the operating system and applications. (The disk paging file, also called a swap file, is a file on the hard disk that serves as temporary, virtual memory storage for code and data.) Virtual memory is the space on the hard disk that Windows 2000 uses as memory. For purposes of monitoring, the most important types of virtual memory are committed memory (shown under MemoryCommitted Bytes) that the system sets aside for a process in the paging file and available memory (shown under MemoryAvailable Bytes) that is not in use by a process. (Another type of memory managed by Windows 2000 is reserved memory, which the system sets aside for a process, but which might not be entirely used.) The following sections describe the influence of the cache and the paging file on performance and explain how best to adjust these for optimal memory usage.

Understanding Memory and the File System Cache

Windows 2000 allocates a portion of the virtual memory in your system to the file system cache. The file system cache is a subset of the memory system that retains recently used information for quick access. The size of the cache depends on the amount of physical memory installed and the memory required for applications. The operating system dynamically adjusts the size of the cache as needed, sharing memory optimally between process working sets and the system cache.

Microsoft® Windows® 2000 Server provides a user interface for adjusting the size of the file system cache, but this user interface is not available in Windows 2000 Professional. For information about adjusting the file-system cache size on systems running Windows 2000 Server, see "Evaluating Memory and Cache Usage" in the Microsoft® Windows® 2000 Server Resource Kit Server Operations Guide.

Adjusting Paging File Size

For virtual-memory support, Windows 2000 creates one paging file called Pagefile.sys on the disk or volume on which the operating system is installed. The default size is equal to 1.5 times the amount of physical memory. A small paging file limits what can be stored and might exhaust your virtual memory for applications. If you are short on RAM, more paging occurs, which generates extra activity for your disks and slows response times for the system.

Because the size and location of paging files can affect your system's performance, you might want to modify them. Also, because maintaining multiple files on multiple physical drives can improve performance, you might want to add a paging file. Figure 28.2 shows the Virtual Memory dialog box, which you use to change your paging file settings. See Windows 2000 Professional Help for specific instructions.

Figure 28.2 Virtual Memory Dialog Box 

The following guidelines describe how to optimize the paging file.

Set the Same Initial and Maximum Size

Setting the paging file's initial size and maximum size to the same value increases efficiency because the operating system does not need to expand the file during processing. Setting different values for initial and maximum size can contribute to disk fragmentation.

Expand the Default Size

Expanding the default size of the paging file can increase performance if applications are consuming virtual memory and the full capacity of the existing file is being used. To determine how large your paging file needs to be based on your system workload, monitor the Process (_Total)Page File Bytes counter. This indicates, in bytes, how much of the paging file is being used.

You can also determine the appropriate size of a paging file by multiplying the Paging File% Usage Peak counter value by the size of Pagefile.sys. The % Usage Peak counter indicates how much of the paging file is being used. Consider expanding the page file whenever either this counter reaches 70 percent of the total size in bytes of all paging files or the Memory% Committed Bytes In Use counter reaches 85 percent, whichever occurs first.

A large paging file uses disk storage space, so do not create a large paging file on a disk that is very active (for example, one that services heavy application or network activity) or one that has limited space. Change the file size gradually and test performance until you find the optimal balance between paging file and disk space usage. The operating system requires a minimum of 5 MB of free space on a disk. For more information, see "Examining and Tuning Disk Usage" in this book.

Move the Paging File

If disk space on your boot volume is limited, you can achieve better performance by moving the paging file to another volume. However, you might want to leave a smaller paging file on the boot volume and maintain a larger file on different volume with more capacity for the sake of recoverability. Depending on how you have configured your system's startup and recovery options, the configuration might require that you maintain a paging file of a certain size on the boot volume. Therefore, make sure to consider your startup and recovery settings when planning to move the paging file. For more information about startup and recovery options such as writing debugging information, see Windows 2000 Help.

Use Multiple Disks

Although Windows 2000 supports a limit of 4,095 MB for each paging file, you can supply large amounts of virtual memory to applications by maintaining multiple paging files. Spreading paging files across multiple disk drives and controllers improves performance on most modern disk systems because multiple disks can process input/output (I/O) requests concurrently in a round-robin fashion.

A mirrored or striped volume is a good candidate for the placement of a paging file. Placing the paging file on its own logical partition can prevent file fragmentation. Creating multiple paging files on a single logical volume or partition does not improve performance.

If you find that page writing and disk writing or page reading and disk reading are equivalent on a logical disk, splitting the paging file onto separate volumes is helpful.

Note To see how the paging file is used during memory shortages, start the LeakyApp tool on the Windows 2000 Resource Kit companion CD, which simulates memory leaks for monitoring purposes. While running LeakyApp, monitor Paging File% Usage Peak and Process(_Total)Page File Bytes. Log these counters to get an idea of the rate of growth of the paging file.

Establishing a Baseline for Memory

After determining that you have an adequate amount of physical memory and that your configuration is appropriate, examine your physical memory usage under a normal workload to establish a baseline or reference point for physical memory usage. The baseline is generally not a single value but a range within which physical memory usage can fluctuate and still provide acceptable performance. You can use the baseline to identify trends, such as increasing physical memory demands over time, or to recognize problems that arise from a sudden change.

To determine a baseline for your system, use the following counters to create logs of memory usage over an extended period (from several weeks to a month).

As you monitor the values of these counters, you might see occasional spikes. Typically, you can exclude these from your baseline because it is the consistent, repetitive values with which you are most concerned; the range of values that seem to appear consistently constitutes your baseline. When values fall outside of these ranges for extended periods, follow the instructions provided in this chapter to investigate the variations.

Virtual Memory Usage

Even if your system exceeds the minimum physical memory requirements for the operating system, you might face situations in which you do not have enough physical memory. For example, if you run several memory-intensive applications or if several users share your computer, the available physical memory of your system might be consumed, affecting your system's performance.

To see how much virtual memory your Windows 2000 Professional–based computer uses, start all applications and use Task Manager to see the Peak Commit Charge value. This value appears in the Commit Charge box on the Performance tab. Commit charge is the number of pages reserved for virtual memory that are backed by the paging file.

Peak committed memory is the highest amount of virtual memory (in bytes) that has been committed over this sample. To be committed, these bytes must either have a corresponding amount of storage available on disk or in main memory. Compare this value against the size of the paging file to determine whether the paging file is sized appropriately.

Under Computer Management, use Shared Folders under System Tools to view this information.

Default Services Memory Consumption

In general, Windows 2000 has been optimized so that only the most commonly used services run by default, and you do not have to turn off any services. However, you can reduce the memory requirements of your system by turning off some of the default services provided by the operating system. Administrators have access to Services in the Administrative Tools menu by default.

To stop a service

This procedure stops the service for the current session. To disable the service permanently, you need to change the value for service startup in the properties dialog box for the service. To use this dialog box, click Services in the Administrative Tools menu or in the Computer Management console. Right-click the service you want to change, select Properties in the shortcut menu, and then change the value to Disabled in the Startup type box.

Investigating Memory Problems

After you have observed memory usage under normal conditions and established your memory baseline, you might notice that the memory counters sometimes stray from the typical range. The following sections describe how to investigate conditions that cause memory values to deviate from the baseline.

The following activities help you to learn about and analyze memory usage and memory bottlenecks by using System Monitor counters and other tools:

Table 28.1 summarizes the most important counters to monitor for analyzing memory usage.

Table 28.1 Counters for Analyzing Memory Usage 

Important The LogicalDisk object counters are not available by default. If you want to monitor the values for these counters, you must first activate the counters by typing diskperf – yv at the Windows command prompt.

Investigating Memory Shortages

Your system can develop a memory shortage if multiple processes are demanding much more memory than is available or you are running applications that leak memory. Monitor the following counters to track memory shortages and to begin to identify their causes.

To maintain a minimum number of available bytes for the operating system and processes, the Virtual Memory Manager continually adjusts the space used in physical memory and on disk. In general, if memory is ample, working set sizes can increase as needed. If the memory supply is barely adequate or very close to the amount required, you might see the operating system trim some working-set sizes when another process needs more memory—at startup, for example. Figure 28.3 illustrates this situation.

Figure 28.3 Working Set Values of Processes as One Process Starts Up 

If the value for MemoryAvailable Bytes is consistently below the system-defined threshold and the value for MemoryPages/sec spikes continuously, it is likely that your memory configuration is insufficient for your needs. To confirm that a high rate of paging is related to low memory, see "Investigating Disk Paging" later in this chapter.

Note You might see a low value for MemoryAvailable Bytes, which is not caused by a memory shortage, in the following situations:

To identify processes associated with low-memory conditions, examine memory usage by specific processes, and determine whether a process is leaking memory as described in "Investigating User-Mode Memory Leaks" and "Investigating Kernel-Mode Memory Leaks" later in this chapter.

If available memory is consistently low (2 MB or less), the computer becomes unresponsive because it is occupied exclusively with disk I/O operations. During paging due to low memory, the processor is idle while waiting for the disk to finish. Therefore, it is important to investigate and correct the cause of a low-memory condition. Notice which processes are running as well as the sizes of their working sets as you monitor memory counters. The processes might need to be updated or replaced if they are contributing to memory shortages and you do not want to acquire additional memory.

For information about how to address a memory shortage, see "Resolving Memory and Cache Bottlenecks" later in this chapter.

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 by using the MemoryPages/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:

Confirming Hard Page Faults

To confirm hard page faults, examine boththe hard page fault rate by using MemoryPages/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. MemoryPages/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 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 MemoryPages/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.

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 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. MemoryPages 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.

Note You might see high levels of paging with MemoryPages/sec when pages are read to and from noncached, memory-mapped files. When these files are used in this way, MemoryPages/sec or MemoryAvailable Bytes is high but MemoryPaging File%Usage and MemoryCache Faults/sec are normal to low.

Figure 28.4 Paging Activity on a System with Low Memory

The other component of MemoryPages/sec, MemoryPages 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, MemoryPages 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 disk's workload, a memory shortage is causing a disk bottleneck. Start by looking at MemoryPage 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 disk's 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 MemoryPage Reads/sec and PhysicalDiskDisk 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 PhysicalDiskAvg 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 PhysicalDiskDisk 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 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 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 

Investigating User-Mode Memory Leaks

A memory leak occurs when applications allocate memory for use but do not free allocated memory when finished. As a result, available memory is used up over time, often causing the system to stop functioning properly. Therefore, it is important to investigate the causes of all memory leaks. This section describes how to identify memory leaks, including ones that affect the critical nonpaged memory pool, and where to find tools and information that can help reduce memory leaks.

Note It is sometimes possible to mistake an increase in system load for a memory leak. To distinguish between these conditions, observe the Memory and Process counters over a number of days. If you see the system first reach a steady state, then attain a level of increased load (usually achieved during some peak portion of the day), and then fall again, it is likely that you are seeing variations in load rather than a leak. On network computers, look at user sessions and throughput rates, such as transferred bytes per second, to eliminate workload as a factor.

Identifying a Memory Leak

The symptoms of a memory leak include the following:

If you suspect that a particular application or service is causing a memory leak, investigate the memory use of your applications by using the following counters:

Monitor these counters over a period ranging from two hours to a few days. Logging is recommended, both because of the overhead of monitoring multiple instances of the Process counters and because leaks tend to manifest themselves slowly.

In addition, to isolate the problem and avoid unnecessary overhead, monitor from a remote computer, if possible. Network activity or interaction with other computers can interfere with the results.

Memory Leaks and the Nonpaged Pool

Although any leak is serious, memory leaks are of particular concern when they involve the nonpaged pool. Many system services allocate memory from the nonpaged pool because they need to reference it when processing an interrupt and cannot take a page fault at that time. To identify whether or not a leak affects the nonpaged pool, include the following counters in your monitoring:

The counters on the Memory object monitor the total size of the nonpaged pool and the number of allocations of pool space for the whole system. The counter on the Process object monitors nonpaged pool space allocated to each process.

To use System Monitor to monitor the nonpaged pool for leaks, follow these steps:

The following additional tools provide information about the paged and nonpaged memory pools as listed in Table 28.2. These tools collect their data from the same sources.

Table 28.2 Tools That Provide Information About Memory Pools 

1 These tools are useful because they show allocations on a per-process basis.

For information about installing and using the Windows 2000 Support Tools and Support Tools Help, see the file Sreadme.doc in the SupportTools folder of the Windows 2000 operating system CD.

For a quick demonstration of a memory leak, start LeakyApp, a test tool on the Windows 2000 Resource Kit companion CD, and observe the values of the monitored counters. Notice the steady increase in the following counters: MemoryPages/sec, Process(LeakyApp)Working Set, and Process(LeakyApp)Private Bytes.

Figure 28.7 illustrates counter activity during a memory leak generated by the LeakyApp tool.

Figure 28.7 Process Memory Activity During a Memory Leak

Although the memory leak illustrated in Figure 28.8 has a systemic effect, the problem can be tracked to a single cause—the leaking application. If you have an application that exhibits similar behavior, it is recommended that you either modify it (if you have access to the source code) or replace it with another program.

Developer tools for analyzing and tuning memory usage by applications are available on the Windows 2000 Resource Kit companion CD. For more information about developer tools, see the MSDN link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/default.asp.

The following tools optimize memory-intensive applications.

The nonpaged pool size and the paged pool size are set by default during Windows 2000 Setup based on your memory configuration. The maximum nonpaged pool size is 256 MB. The maximum paged pool size is approximately 470 MB. The actual size varies depending on your configuration. More physical memory results in less paged pool because the virtual address space must instead be used to contain more critical memory-management structures. The pool sizes are defined in the registry in the HKEY_LOCAL_MACHINE System CurrentControlSet Control Session ManagerMemory Management subkey.

To extend the file system cache working set from 512 MB to 960 MB, set the value of the PagedPoolSize registry entry to 192000000, set SystemPages to 0, and make sure that the system is optimized for file sharing with LargeSystemCache set to 1. To make the maximum virtual address space available to the paged pool, set the PagedPoolSize registry entry to –1, provided your system is not using the /3GB Boot.ini switch.

Typically you do not need to set the NonPagedPoolSize entry because on systems with more than 1.2 GB of memory, the system automatically defaults to the maximum nonpaged pool size. If you need to set the NonPagedPoolSize value, set it to the value you want (in bytes); do not set it to – 1.

Investigating Kernel-Mode Memory Leaks

Kernel-mode processes, such as device drivers, can also leak memory when bytes are allocated but not freed. Again, you typically track these over a period of several hours or days, but instead of relying on System Monitor counters, use Pool Monitor (Poolmon.exe). For information about Pool Monitor, see Windows 2000 Support Tools Help. For information about installing and using the Windows 2000 Support Tools and Support Tools Help, see the file Sreadme.doc in the SupportTools folder of the Windows 2000 operating system CD.

Pool Monitor (Poolmon.exe) shows the amounts of nonpaged and paged memory that were allocated and freed, calculates the difference between these, and associates the data with a function tag to help you identify the process involved. By default, Windows 2000 is configured not to collect pool information because of the overhead. To use Poolmon, you must enable the pool tag signal. Use Gflags.exe to make the change. In Gflags, select the Enable Pool Tag check box. For information about using Poolmon and Gflags, see Support Tools Help. For information about installing and using the Windows 2000 Support Tools and Support Tools Help, see the file Sreadme.doc in the SupportTools folder of the Windows 2000 operating system CD.

The pool tag is a mechanism for identifying the driver or other part of the kernel allocated to a particular portion of memory. These tags can be examined to reveal memory leaks and pool corruption, and the offending code component can be determined by finding which code component is allocated to which tag. Look for a tag with rapidly increasing byte counts that does not free as many bytes as it allocates, and verify that this tag corresponds to a function for which the increasing memory allocation might be appropriate. If it does not appear appropriate, it might be necessary to debug and tune the application to eliminate the leak.

Monitoring the Cache

The Windows 2000 file system cache is an area of memory into which the I/O system maps recently used data from disk. When processes need to read from or write to the files mapped in the cache, the I/O Manager copies the data from or to the cache, without buffering or calling the file system, as if it were an array in memory. Because memory access is quicker than a file operation, the cache provides an important performance boost to the processes.

Cache object counters provide information about data hits and misses and about file I/O operations that reflect how efficiently their applications access data in the file system cache. However, because the cache counters are based on the views mapped by the Cache Manager and not on data from the Virtual Memory Manager, the cache counter values do not provide definitive information about bottlenecks. In some cases, cache counters can report low rates of hits or high rates of misses, suggesting that the system is accessing the disk when, in fact, the requested data has been retrieved from memory. This can occur if virtual addresses mapped by the Cache Manager no longer exist, for example, because the file has closed. To obtain more accurate data on I/O bottlenecks, use the MemoryPages Input/sec counter.

The cache itself can never really have a bottleneck because it is just a part of physical memory. However, when there is not enough memory to create an effective cache, the system must retrieve more data from disk, resulting in I/O operations that can impact overall performance. Such a shortage of cache space can be considered a cache bottleneck.

Cache bottlenecks are of greatest concern to users of Windows 2000 Professional–based computers running computer-aided design/computer-aided manufacturing (CAD/CAM) applications or large databases accessing large blocks of multiple files that rely on the cache. The cache counters can reveal that a small cache (based on a short supply of memory) is hurting system performance.

With memory-mapped file I/O, an entire file can be opened without actually being read into memory. Only the views (smaller portions of the file) are mapped into the process's address space just before I/O operations are performed. Memory-mapped I/O keeps the cache size small. For more information about memory-mapped I/O, see the Software Development Kit (SDK) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/default.asp.

Developers who want to understand how their programs use the cache for read and write operations might also want to monitor the cache. Data requested by an application is mapped to the cache and then c