How to Prevent FileCache from Eating Up All the RAM

How to Prevent FileCache from Eating Up All the RAM


More and more RAM is taken for FileCache. This can, especially on x64 systems, impact performance of the system.


While in x86 systems, the maximum is limited at 1GB for the SystemFileCache, in x64 systems, the limit can be larger then the installed ram. There is a detailed BLOG
post discussing the issue here.


Unfortunately, to set the limits, you have to use the Windows API. So either, if you have access to e.g. Visual Studio, you make yourself a little console application using the SetSystemFileCacheSize function (see here for MSDN Library entry) or you search on the internet for "SetSystemFileCacheSize", there are a few freeware tools out there (e.g. here)


The API sets the limits for the running session. If you reboot, the limits are lost again. So if you want to set the limits without the need of user intervention after a reboot, make a planned task with trigger "At system startup".

Leave a Comment
  • Please add 8 and 6 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
  • FZB edited Revision 1. Comment: typo

  • FZB edited Original. Comment: added comment

Page 1 of 1 (2 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • The issue doesn't occur in Server 2008 R2, only till 2008:

    "Windows 7 and 2008 R2 has several Memory Manager changes that should help mitigate this problem. That being said, don't expect that the cache won't utilize a fair share of physical RAM if there is a lot of demand for cached I/O. It may use quite a bit of physical RAM, but not at the expense of other processes and it shouldn't completely deplete available memory. The other thing to keep in mind is that under R2 you may not be experiencing a cache consumption problem, but an I/O bottleneck. "

    The NTDebugging blog created a service to workaround this:

  • Hello Andre, this issue still occurs. I know there were supposed to be improvements in Windows 2008 R2, but it still happens (both with machines i have on site as well as regulary for others stated in the forums). The service in the blog isnt working for Windows 2008 R2 though. I can dig up some links to forum posts where it happens in Windows 2008 R2 and the solution did improve the situation. Haven't tested it yet with Windows 8, will do so when the beta shows up for MSDN subscribers.

  • Are you sure it's a cache issue? Run RAMMap or LiveKD (!memusage, !vm) to see why the Server uses too much RAM.

  • I am fairly sure, RAMMap, Resource Monitor, Task Manager all suggest its the cache, and the moment i limit it (which releases cache used above the limit), the responsiveness of the affected machine gets better instantly. I know Microsoft did work on filesystemcache between release 2008 and 2008 R2, though to my experience it still shows up (and i see the issue every now and then in the forums).

  • FZB edited Original. Comment: added comment

  • can you post a link to such an issue?

  • here is an example of someone who replyed with the outcome:

  • ok, here is also a comment, that it still occurs:

    So if you have the issue, contact the support for an updated service.

  • FZB edited Revision 1. Comment: typo

  • We have this problem ( ) with Server 2008 R2 as well. I tried calling Microsoft technical support and they told me they no longer have the file and to do anything about it they want a credit card number.  We've already forked out 10's of thousands of $ for this software and CALs to use it, I don't see why we should have to pay even more when KB976618 clearly says that 2008 R2 has a problem, and MS Tech Support have a file ready to make it work like it is supposed to.

    What can we do now?

    Switch to Linux...?

  • I've pulled out a lot of hair and figured out a workaround myself. As MS KB976618 states, the metafile cache issue can be worked around by using the windows API SetSystemFileCacheSize, and if you are like me and don't want to run a binary from some unknown 3rd party on your production servers you want some code you can inspect before running on those servers.

    The DynCache tool for 2008 R2 is practically impossible to obtain from M$ without paying for a support case.

    So after weeks of hair pulling I've written a couple of powershell scripts and posted them on these pages



Page 1 of 1 (11 items)