لطفا منتظر باشید ...
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 shortagesInvestigating disk pagingInvestigating user-mode memory leaksInvestigating kernel-mode memory leaksMonitoring the cacheResolving 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 ObjectCounter |
|---|---|
| Memory shortages | MemoryAvailable Bytes Process (All_processes)Working SetMemoryPages/secMemoryCache Bytes |
| Frequent hard page faults | MemoryPages/secProcess (All_processes)Working Set MemoryPages Input/secMemoryPages Output/sec |
| Excess paging with a disk bottleneck | MemoryPage Reads/secPhysical DiskAvg. Disk Bytes/Read |
| Paging file fragmentation | PhysicalDiskSplit IOssecPhysicalDisk% Disk Read TimePhysicalDiskCurrent Disk Queue LengthProcessHandle Count |
| Memory leaks; memory-intensive applications | MemoryPool Nonpaged AllocationsMemoryPool Nonpaged BytesMemoryPool 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 | CacheCopy Read Hits %CacheCopy Reads/secCacheData Map Hits %CacheData Maps/secCacheMDL Read Hits %CacheMDL Reads/secCachePin Read Hits %CachePin Reads/secTo identify cache bottlenecks, also use MemoryPages 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.
MemoryAvailable 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. MemoryPages/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 MemoryPages/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.
NOTETo 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.
You might see a low value for MemoryAvailable 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 MemoryCache Bytes. You typically see MemoryCache Bytes rise as MemoryAvailable 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.
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:
To confirm hard page faulting, use the following Memory and Process counters:
MemoryPages/sec Process (All_processes)Working SetMemoryPages Input/secMemoryPages Output/sec
To understand the impact of page faulting on the disk, compare the number of reads and read bytes measured by the following counters:
MemoryPage Reads/secPhysicalDiskDisk Reads/sec PhysicalDiskAvg. Disk Read Bytes/sec
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.
NOTEWhen 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.
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.
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 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 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 Performance" 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:
MemoryAvailable Bytes reports available bytes; its value tends to fall during a memory leak. MemoryCommitted 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 BytesMemoryPool Nonpaged AllocsProcess(process_name)Pool Nonpaged Bytes
NOTEThe 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:
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.
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 ProcessHandle Count, ProcessPrivate Bytes, ProcessNonpaged Pool Bytes, ProcessPaged Pool Bytes, and ProcessThreads. 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 |
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://windows.microsoft.com/windows2000/reskit/webresources. 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_MACHINESystem
CurrentControlSetControlSession 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://windows.microsoft.com/windows2000/reskit/webresources.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 copied from there. Data changed by applications is written from the cache to disk by the lazy writer system thread or by a write-through call from the application. The lazy writer thread in the system process periodically writes changed pages from the modified page list back to disk and flushes them from the cache. When a page is flushed from the cache, changed data is written from the page in the cache to the disk and the page is deleted from the cache. Thus, monitoring the cache is like watching your application I/O. Remember, however, that if an application uses the cache infrequently, cache activity has an insignificant effect on the system, on the disks, and on memory.
Understanding the Cache Counters
Use the following System Monitor Cache and Memory counters to measure cache performance. CacheCopy Read Hits % Monitor this counter for hit rates and miss rates. Any value over 80 percent indicates that the application uses the cache very efficiently. Compare this counter against CacheCopy Reads/sec to see how many hits you are really getting. Even though the hit percentage is small, if the rate of operations is high, this might indicate better cache effectiveness than a high percentage with a low rate of operations.
NOTECacheCopy Reads/sec Observe this counter to see the rate at which the file system attempts to find application data in the cache without accessing the disk. This is a count of all copy read calls to the cache, including hits and misses. Copy reads are the usual method by which file data found in the cache is copied into an application's memory buffers.CacheData Flush Pages/sec Review this counter for the rate at which both applications change pages of cached data and the pages are written back to disk. This includes pages that have been written by the system process when many changed pages have accumulated, pages that have been flushed so that the cache can be trimmed, and disk writes that are caused by an application write-through request.CacheData Flushes/sec Monitor this counter for the rate at which cache data is being written back to disk. This counter reports application requests to flush data from the cache and is an indirect indicator of the volume and frequency of application data changes.CacheData Maps/sec Examine this counter for the rate at which file systems map pages of a file into the cache for reading. This counter reports read-only access to file system directories, the file allocation table (FAT) in the FAT file system, and the Master File Table in the NTFS file system. This counter does not reflect cache use by applications.CacheFast Reads/sec Observe this counter for the rate at which applications bypass the file system and access data directly from the cache. A value over 50 percent indicates the application is behaving efficiently. Fast reads reduce processor overhead and are preferable to I/O requests.CacheLazy Write Flushes/sec Review this counter for the rate at which an application changes data, causing the cache to write to the disk and flush the data. If this value reflects an upward trend, memory might be becoming low. Lazy write flushes are a subset of data flushes. The lazy writer thread in the system process periodically writes changed pages from the modified page list back to disk and flushes them from the cache. This thread is activated more often when memory needs to be released for other uses. This counter counts the number of write and flush operations, regardless of the amount of data written.CacheLazy Write Pages/sec Examine this counter value for the rate at which pages are changed by an application and written to the disk. If the counter value is increasing, this can indicate that memory is becoming low. CacheLazy Write Pages are a subset of Data Flush Pages.CacheRead Aheads/sec Use this counter to monitor the rate at which the Cache Manager detects that the file is being accessed sequentially. Sequential file access is a very efficient strategy in most cases. During sequential file access, the Cache Manager can read larger blocks of data into the cache on each I/O, thereby reducing the overhead per access.MemoryCache Bytes Monitor this counter for growth or shrinkage of the cache. The value includes not only the size of the cache but also the size of the paged pool and the amount of pageable driver and kernel code. Essentially, these values measure the system's working set.MemoryCache Faults/sec Observe this counter for the rate at which pages sought in the cache were not found there and had to be obtained elsewhere in memory or on the disk. Compare this counter against MemoryPage Faults/sec and Pages Input/sec to determine the number of hard page faults, if any.
For best results, monitor the CacheCopy Read Hits % counter using the graph view rather than the report view. Hit percentage rates frequently appear as spikes that are hard to detect in a report.
NOTE
Performance Meter (Perfmtr.exe), a tool on the Windows 2000 Resource Kit companion CD and the SDK, lists among other statistics, data about the file system cache. For more information, see the Windows 2000 Resource Kit Tools Help (W2rktools.chm) or the SDK documentation.
Interpreting Changes in Cache Counter Values
Administrators need to watch for signs from the cache counters that low memory is causing insufficient cache size and consequently that cache usage is resulting in unnecessary disk I/O, which degrades performance. Monitor for the following conditions, using the counters as described. (Options for improving these conditions include defragmenting the disk and adding memory.)Reduction in Cache SizeWhen memory becomes scarce and working sets are trimmed, the cache is trimmed as well. If the cache grows too small, cache-sensitive processes are slowed by disk operations. To monitor cache size, use the MemoryCache Bytes and MemoryAvailable Bytes counters. Note that the effect of a smaller cache on applications and file operations depends on how often and how effectively applications use the cache.Frequent Cache Flushing Frequent cache flushing might occur if data is written to the disk frequently in order to free pages. Data flush counters reflect cache output. Monitor the CacheData Flushes/sec and CacheLazy Writes Flushes/sec counters. CachePin Reads/sec tells you how often the cache is reading data with the intention of writing it. A pin read occurs when data is mapped into the cache just to be changed and is then written back to disk. It is pinned in the cache to be sure the data being changed is not written to disk until the update is complete. Creating a file or changing its attributes results in a pin read. Changing file contents does not result in a pin read. CachePin Reads/sec can predict flushing activity.High Rates of Cache Misses High cache miss rates indicate that requested data is not available in physical memory and must be retrieved from the disk. Monitor the Cache object counters that record hit percentages and hit rates (such as CacheCopy Read Hits % and CacheCopy Read Hits/sec). Make sure to review both hit percentage and hit activity counters to ensure that your data gives an accurate picture of cache efficiency. For example, you might notice that your hit percentage is very high (90 percent on average), implying that the cache is highly efficient. However, when you examine hit activity, you might notice that only a few copy reads have occurred during the sample. In this case, relying on the percentages would have given you a false impression of cache effectiveness. Therefore, examining hit percentages over a range of activity rates is recommended. High Rates of Cache FaultsAlthough you cannot tell from the MemoryCache Faults/sec counter value alone, an increase in cache faults might mean that hard page faults are occurring, resulting in disk activity. MemoryCache Faults/sec reports fault activity for the system working set, including hard and soft page faults. Because the cache counters do not provide conclusive information about this, you must monitor MemoryPages Input/sec to determine whether hard page faults are occurring. If Cache Faults/sec values increase and hit-percentage counter values decrease, it is likely there is not enough memory to create an efficient cache. When insufficient memory forces the system to maintain a small cache size, disk I/O tends to increase. You can see the impact of cache and memory activity on the disk by adding MemoryPages Output/sec to CacheData Flush Pages/sec. This total is approximately equal to the page equivalent of Disk Write Bytes/sec for the PhysicalDisk counters. As the Pages Output/sec and Data Flush Pages/sec counter values increase, so does the value of Disk Write Bytes/sec, reflecting the increasing disk writing activity. (Differences in values can be attributed to the sampling behavior of System Monitor.) Similarly, there is a corresponding read impact: look at MemoryPages Input/sec; this needs to equal the number of bytes of memory reported under Disk Read Bytes/sec but expressed in pages for the PhysicalDisk counters as described in "Investigating Disk Paging" earlier in this chapter.
