Evaluating Memory and Cache Usage
Evaluating Memory and Cache Usage |
|
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 administrators of Windows 2000 Server–based computers and to users of Windows 2000 Professional–based computers running CAD/CAM applications or large databases accessing large blocks of multiple files that rely on the cache. Administrators of server computers need to monitor cache counters because these provide indirect indications of the memory supply. Windows 2000 Server defines a large system cache by default to maximize the likelihood that data is found in memory, rather than retrieved from disks. The cache counters can reveal that a small cache (based on a short supply of memory) is hurting system performance.
Note
Many Web servers or large database applications, such as SQL Server, maintain a separate cache and do not use the file system cache. In addition, they might have their own cache-monitoring counters.
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.
Use the following System Monitor Cache and Memory counters to measure cache performance. For instructions based on specific symptoms, see "Interpreting Changes in Cache Counter Values" later in this chapter.
Cache\Copy 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 with Cache\Copy 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.
Note
For best results, monitor the Cache\Copy 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.
Cache\Copy 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.
Cache\Data Flush Pages/sec Review this counter for the rate at which 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.
Cache\Data 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.
Cache\Data 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.
Cache\Fast 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.
Cache\Lazy 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.
Cache\Lazy 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. Cache\Lazy Write Pages are a subset of Data Flush Pages.
Cache\Read 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.
Memory\Cache Bytes Monitor this counter for growth or shrinking 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.
Memory\Cache 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 with Memory\Page Faults/sec and Pages Input/sec to determine the number of hard page faults, if any.
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.
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.)
When 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 Memory\Cache Bytes and Memory\Available 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 might occur if data is written to the disk frequently in order to free pages. Data flush counters reflect cache output. Monitor the Cache\Data Flushes/sec and Cache\Lazy Writes Flushes/sec counters.
Cache\Pin 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. Cache\Pin Reads/sec can predict flushing activity.
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 Cache\Copy Read Hits % and Cache\Copy 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.
For computers running Windows 2000 Server, you might also want to monitor MDL Read Hits % and MDL Reads/sec. The Server service might use MDL reads rather than copy reads for large data transfers. MDL reads rely on direct memory access (DMA) for better overall performance.
Although you cannot tell from the Memory\Cache Faults/sec counter value alone, an increase in cache faults might mean that hard page faults are occurring, resulting in disk activity. Memory\Cache 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 Memory\Pages Input/sec to determine if 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 Memory\Pages Output/sec to Cache\Data 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 Memory\Pages Input/sec; this should equal the number of bytes of memory reported under Disk Read Bytes/sec but expressed in pages for the PhysicalDisk counters as described in "Assessing the Effect of Page Faults on the Disk" earlier in this chapter.