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

•	For general information about performance monitoring, see "Overview of Performance Monitoring" in this book.
•	For more information about developer tools see the Microsoft ® Windows ® 2000 Resource Kit companion CD, or see the MSDN link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/default.asp .

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.

•	See "Overview of Memory Monitoring" later in this chapter.

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.

•	See "Determining the Amount of Installed Memory" later in this chapter.

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.

•	See "Establishing a Baseline for Memory" later in this chapter.

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.

•	See "Investigating Memory Problems" later in this chapter.

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.

•	See "Resolving Memory and Cache Bottlenecks" later in this chapter.

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.

•	See "Resolving Memory and Cache Bottlenecks" later in this chapter.

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.

•	Changed from Windows NT 4.0, Windows 2000 Professional enlarges the default size of the paging file to 1.5 times the amount of installed random access memory (RAM).
•	Users of Microsoft® Windows NT® Workstation version 4.0 will notice the new counters under the Memory performance object in System Monitor: Available KBytes and Available MBytes, reporting the amount of available memory in kilobytes and megabytes, respectively, rather than only in bytes as reported by Memory\Available Bytes . The Memory performance object counters are similar to the Memory Manager items . The Cache object counters are similar to the Disk Cache items available in Windows 98 System Monitor, but are named differently in Windows 2000 .
•	Task Manager's display of file-system cache size has been modified from Windows NT Workstation 4.0 for greater accuracy. The value reported by System Cache in Task Manager represents the currently mapped file system cache plus pages in transition to disk. These were not included in values reported under Windows NT 4.0.

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:

•	Determine the amount of physical memory that is currently installed, and compare it against minimum operating system requirements.
•	Read "Understanding Memory and the File System Cache" later in this chapter for information about the relationship between system memory and the file system cache.
•	Establish a baseline for memory usage on your computer by determining performance ranges for low or idle, average, and peak usage periods.
•	Optimize the system memory configuration to the system workload, including verifying cache and paging file sizes.

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

•	Look at memory characteristics of processes using the Process\Working Set and Process\Private Bytes counters. The Working Set counter reports the amount of committed memory allocated to the process. This might include shared and private bytes currently residing in physical memory. The Private Bytes counter reports memory allocated exclusively to the process. Working set monitoring is important because, when memory is in short supply, the operating system trims the working sets of processes and paging occurs. (The working set of a process is the amount of physical memory assigned to that process by the operating system.)
•	Monitor the counters listed in "Investigating Disk Paging" later in this chapter to understand the relationship between the amount of paging and the amount of disk activity and their effect on overall performance. Excessive paging can burden the disk.
•	Determine the effectiveness of the file system cache. Your system performs better when it can find requested data in the cache, rather than when it must read from the disk.
•	Learn how to tune the working  sets of applications, if you have access to source code. Efficient applications maintain a small working set without generating page faults.

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 Memory\Committed Bytes) that the system sets aside for a process in the paging file and available memory (shown under Memory\Available 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).

•	\Memory\Pages/sec
•	\Memory\Available Bytes
•	\Paging File(_Total)\% Usage

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  

1.	From the Start menu, point to Programs and Administrative Tools , and then click Services .
2.	Right-click the name of the appropriate service, and then click Stop .

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:

•	Investigating memory shortages
•	Investigating disk paging
•	Investigating user-mode memory leaks
•	Investigating kernel-mode memory leaks
•	Monitoring the cache
•	Resolving memory and cache bottlenecks

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

Table 28.1 Counters for Analyzing Memory Usage  

To monitor for	Use this Object\Counter
Memory shortages	Memory\Available Bytes Process (All_processes)\Working SetMemory\Pages/secMemory\Cache Bytes
Frequent hard page faults	Memory\Pages/secProcess (All_processes)\Working Set Memory\Pages Input/sec Memory\Pages Output/sec
Excess paging with a disk bottleneck	Memory\Page Reads/secPhysical Disk\Avg. Disk Bytes/Read
Paging file fragmentation	PhysicalDisk\Split IOs\secPhysicalDisk\% Disk Read TimePhysicalDisk\Current Disk Queue LengthProcess\Handle Count
Memory leaks; memory-intensive applications	Memory\Pool Nonpaged AllocationsMemory\Pool Nonpaged BytesMemory\Pool Paged BytesProcess(process_name)\Pool Nonpaged BytesProcess(process_name)\Handle CountProcess(process_name)\Pool Paged BytesProcess(process_name)\Virtual BytesProcess(process_name)\Private Bytes
Cache Manager efficiency	Cache\Copy Read Hits %Cache\Copy Reads/secCache\Data Map Hits %Cache\Data Maps/secCache\MDL Read Hits %Cache\MDL Reads/secCache\Pin Read Hits %Cache\Pin Reads/secTo identify cache bottlenecks, also use Memory\Pages Input/sec with these counters.

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.

•	Memory\Available Bytes indicates how much physical memory is remaining after the working sets of running processes and the cache have been served.
•	Process ( All_processes )\Working Set indicates the number of pages that are currently assigned to processes . When there is ample memory, the working set structures can fill with pages that are not currently needed to do work but that were needed in the past and might be needed in the future . Because there is no memory shortage, the working set structures are not trimmed . As a result the working set approximates pages that have been referenced in a longer period of time . However, when memory is in short supply, the working set might be trimmed . As a result, the working set in that case approximates the number of pages referenced in a much shorter period of time .
•	Memory\Pages/sec indicates the number of requested pages that were not immediately available in RAM and had to be read from the disk or had to be written to the disk to make room in RAM for other pages. If your system experiences a high rate of hard page faults, the value for Memory\Pages/sec can be high.

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 Memory\Available Bytes, which is not caused by a memory shortage, in the following situations:

•	During large file-copy operations such as a system backup. In this case, you can verify that the copy operation is the cause by also monitoring Memory\Cache Bytes. You typically see Memory\Cache Bytes rise as Memory\Available Bytes falls. Otherwise, you need to investigate the cause as described in this chapter.
•	The working sets of processes have become smaller and there is no demand for pages for other purposes. In this case the number of available bytes might be low but there is no need to trim working sets and there are few if any page faults.

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 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:

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

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 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 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 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 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 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:

•	A gradually worsening response time.
•	The appearance of an error message, shown in Figure 28.6, indicating that the system is low on virtual memory. (Another message box might precede this, indicating that virtual memory has been exceeded and that the system has increased the paging file size automatically.)    Figure 28.6 Out of Virtual Memory Error Message
•	The appearance of error messages indicating that system services have stopped.

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:

•	Memory\Available Bytes reports available bytes; its value tends to fall during a memory leak.
•	Memory\Committed Bytes reports the private bytes committed to processes; its value tends to rise during a memory leak.
•	Process( process_name )\Private Bytes reports bytes allocated exclusively for a specific process; its value tends to rise for a leaking process.
•	Process( process_name )\Working Set reports the shared and private bytes allocated to a process; its value tends to rise for a leaking process.
•	Process( process_name )\Page Faults/sec reports the total number of faults (hard and soft faults) caused by a process; its value tends to rise for a leaking process.
•	Process( process_name )\Page File Bytes reports the size of the paging file; its value tends to rise during a memory leak.
•	Process( process_name )\Handle Count reports the number of handles that an application opened for objects it creates. Handles are used by programs to identify resources that they must access. The value of this counter tends to rise during a memory leak; however, you cannot rule out a leak simply because this counter's value is stable.

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:

•	MemoryPool Nonpaged Bytes
•	MemoryPool Nonpaged Allocs
•	Process(process_name) Pool Nonpaged Bytes Note Because the internal counters used by Task Manager, Process Monitor, and System Monitor to measure the size of the nonpaged pool for each process are not precise, it is recommended that you monitor changes in the overall pool size over time (a few days, for example), rather than rely on the absolute, instantaneous values reported for each process . The counter values are estimates that count duplicate object handles as well as space for the object . Also, because the process pool size counts are rounded to page size, pool space is overestimated when a process uses only part of a page . In contrast, total pool size counts are precise . Therefore, the sum of pool sizes for each process might not equal the value for the whole system.

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:

•	Record the size of the nonpaged pool when the system starts. Then log the Memory and Process objects for several days; a 10-minute update interval is sufficient.
•	Review the log for changes in size of the nonpaged pool. Usually, you can associate any increases in the size of the pool, as indicated by MemoryPool Nonpaged Bytes, with the start of a process, as indicated by Process% Processor Time. Also look at individual Process object counters such as Process\Handle Count, Process\Private Bytes, Process\Nonpaged Pool Bytes, Process\Paged Pool Bytes, and Process\Threads. During a memory leak, you might also see rising values for these counters. When processes are stopped, you typically see a decrease in pool size. Any growth in the nonpaged pool is considered abnormal, and you need to distinguish which process is causing the change in pool size.  You might also want to monitor the number of active threads before and after running the process (use the Performance tab in Task Manager or the ObjectsThreads or Process(_Total)Thread Count counters). A process that is leaking memory might be creating a large number of threads; these appear when the process starts and disappear when the process stops.
•	Watch the value of MemoryPool Nonpaged Bytes for an increase of 10 percent or more from its value at system startup to see whether a serious leak is developing.

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  

Tool Name	Description	Location
Memsnap (memsnap.exe)1	Records system memory usage to a log file.	Windows 2000 Support Tools
Process Monitor (pmon.exe)1	Provides total and per process values for nonpaged and paged pool memory. Also monitors the committed memory values shown in the Pmon display for increases; the process with the leak typically has an increasing value reported under Commit Charge.	Windows 2000 Support Tools

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 \Support\Tools 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: Memory\Pages/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.

•	Application Monitor (ApiMon) on the Windows 2000 Resource Kit companion CD monitors page faults caused by an application and reports them by using Microsoft® Win32® function calls.
•	The Working Set Tuner (WST) on the Software Development Kit (SDK) analyzes the patterns of function calls in your application code and generates an improved function ordering to reduce physical memory usage. One objective of tuning your working set is to arrive at the smallest possible working set without causing page faults.
•	Virtual Address Dump (Vadump) on the SDK creates a list that contains information about the memory usage of a specified process, including address size, total committed memory for the image, the executable file, each dynamic-link library (DLL), and heap usage.

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 Manager\Memory 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 \Support\Tools 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 \Support\Tools 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 Memory\Pages 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