Partilhar via

Cache and Memory Manager Potential Performance Issues

  • Artigo

Before Windows Server 2012, two primary potential issues caused system file cache to grow until available memory was almost depleted under certain workloads. When this situation results in the system being sluggish, you can determine whether the server is facing one of these issues.

In this topic:

  • Counters to monitor

  • System file cache contains NTFS metafile data structures

  • System file cache contains memory mapped files

Counters to monitor

  • Memory\Long-Term Average Standby Cache Lifetime (s) < 1800 seconds

  • Memory\Available Mbytes is low

  • Memory\System Cache Resident Bytes

If Memory\Available Mbytes is low and at the same time Memory\System Cache Resident Bytes is consuming significant part of the physical memory, you can use RAMMAP to find out what the cache is being used for.

System file cache contains NTFS metafile data structures

This problem is indicated by a very high number of active Metafile pages in RAMMAP output, as shown in the following figure. This problem might have been observed on busy servers with millions of files being accessed, thereby resulting in caching NTFS metafile data not being released from the cache.

RAMMAP view

The problem used to be mitigated by DynCache tool. In Windows Server 2012, the architecture has been redesigned and this problem should no longer exist.

System file cache contains memory mapped files

This problem is indicated by very high number of active Mapped file pages in RAMMAP output. This usually indicates that some application on the server is opening a lot of large files using CreateFile API with FILE_FLAG_RANDOM_ACCESS flag set.

This issue is described in detail in KB article 2549369. FILE_FLAG_RANDOM_ACCESS flag is a hint for Cache Manager to keep mapped views of the file in memory as long as possible (until Memory Manager doesn’t signal low memory condition). At the same time, this flag instructs Cache Manager to disable prefetching of file data.

This situation has been mitigated to some extent by working set trimming improvements in Windows Server 2012 and Windows Server 2012 R2, but the issue itself needs to be primarily addressed by the application vendor by not using FILE_FLAG_RANDOM_ACCESS. An alternative solution for the app vendor might be to use low memory priority when accessing the files. This can be achieved using the SetThreadInformation API. Pages that are accessed at low memory priority are removed from the working set more aggressively.

Performance Tuning for Cache and Memory Manager Subsystems

 

 

Send comments about this topic to Microsoft