Many people ask how to disable pagefile, because they feel the effects of the issue I will ask about. Instead I want to fix the issue, without disabling pagefile.

Windows has the capability of storing on the pagefile RAM that it thinks it might need to page out, although theoretically this help avoid trashing in an emergency, it is deeply annoying to people with systems that have slow HDDs, for example cheap laptops.

For example my current computer: Right now it has 4.8gb of RAM in use, but has about 8gb of current "commit charge"

Using sysinternal tools, I find out that most of the content of page files, are preemptive copies of things in the RAM, that DO look it is low (I have 8gb of ram, thus it is 61% in use), but using RamMap I notice that most of the ram usage is "standby" memory, and most of that "standby" memory is windows cache (the one to make files load faster). with a huge chunk being a binary file that is the sound files of a game.

So, what currently happens: I play some game... windows load it on the RAM, and copy other things to pagefile (making game performance poor), then I stop playing, windows leave the game files cached on the RAM, since the RAM usage is high, it keeps putting more stuff on the pagefile, expecting me to run out of RAM, this make it slow, as it is constantly doing I/O in my extremely bad quality HDD.

But if I look only in the real RAM usage by apps, the commit charge of currently running apps, processes, kernel and shared things used, the real RAM usage should be 2.5gb, RAM and pagefile included.

So, I wanted to try instead of telling windows to not cache (the caching is kinda cool), or to disable pagefile, I wanted to tell it to NOT use the pagefile unless it really needs to (for example if physical ram usage - standby physical ram usage > 80% of physical ram).

Anyone know how I do that?

  • update to Windows 10: superuser.com/a/952142/174557 here the RAM is compressed and stored in SYSTEM process to reduce paging – magicandre1981 Apr 16 '16 at 19:51
  • I honestly hope that I will never have to install win 10 on my personal PC. Although knowing about win 10 helps anyway (there are a bunch of win 10 machines here, and when they break, it is me that has to fix them). – speeder Apr 16 '16 at 19:52
  • "Using sysinternal tools, I find out that most of the content of page files, are preemptive copies of things in the RAM" - what are you looking at that tells you this? How do you know it's "preemptive", and what exactly do you mean by that? n.b.: Windows does not ever "write preemptively to the pagefile." Writes to the pagefile happen when moving pages from the modified page list to the standby list. And pages are only put on the MPL when they've been dropped from working set(s) due to memory pressure. There's nothing "preemptive" or "predictive" about it. – Jamie Hanrahan Apr 17 '16 at 22:17
  • And the new "compressed memory" mechanism is really about avoiding pagefile writes for even longer, before writing to the pagefile. (but due to compression it takes less RAM than it would have to just leave it where it was. And if it does actually have to be written out, less of it has to be written out - or read in later if needed. – Jamie Hanrahan Apr 17 '16 at 22:28
  • It was a bunch of articles that I've read, that windows write to the pagefile to avoid having to do it in a emergency when you actually do need RAM. – speeder Apr 18 '16 at 4:16

After lots of research, I learned that what I asked is literally impossible, you can't tweak Windows to behave better, the best that can be done, is literally disabling page file entirely.

Disabling page file mostly did the trick for me, fixing most of my performance problems (and causing a few other problems), but it was fully worth it.

| improve this answer | |

This will make performance worse, I'm afraid. As you concede, your disk is slow. This means that having as much memory as possible available for use as a disk cache is essential. This is only possible by removing things that are not being accessed from RAM, and that requires writing them out to the pagefile.

If Windows didn't use the pagefile to make more RAM for caching, even more disk I/O would be needed due to the reduced caching. That would make performance worse.

Windows is making the best of a bad situation. The folks who designed the Windows memory management system (from Vista on) knew exactly what they were doing and are leading experts in the design of paging systems on modern hardware. Neither you nor I know better than they do. They didn't do anything majorly wrong that can be fixed by flipping a switch. Sorry, there's no magic "go faster" button.

By the way, modern SSDs have significant write endurance. So if you can't add more RAM, adding a small, cheap SSD for your pagefile is not unreasonable. Obviously, keeping your main files on an SSD would make more of a difference.

| improve this answer | |
  • 1
    So, how having a gigantic binary file with a game music in the RAM, and actual applications I am using on the page file (instead of the RAM) helps my system go faster? – speeder Apr 16 '16 at 19:44
  • @speeder It helped your system go faster in the past. Paging in the bits of the game music as they were needed, reading each one over and over rather than keeping them in RAM, may have made the game unplayable. Now the system needs to adjust to the change in usage, and it will be slow while it does so. That's just the nature of systems with slow disk. – David Schwartz Apr 16 '16 at 19:45
  • Re "actual applications I am using on the page file (instead of the RAM" - sorry but code is almost never paged to the page file. The reason is that code is shared between processes and is almost always read-only. There would be no reason to ever write it to the pagefile. If memory pressure is high, not-recently-accessed code is simply dropped from RAM, as it can always be faulted back in from the exe or dll it came from in the first place. (The exception is if you're debugging the code and set breakpoints in it, but that would only apply to the individual pages in which you set them.) – Jamie Hanrahan Apr 18 '16 at 8:51
  • @JamieHanrahan I understood him to mean pages allocated, modified, and accessed by actual applications he is using rather than the executables/libraries themselves. Of course clean, unmodified pages from file mappings are discardable and do not need to be written to page file. – David Schwartz Apr 18 '16 at 11:38
  • @DavidSchwartz Ok. In any case, pagefile-backed virtual memory - which chiefly consists of process-private v.a.s. and the paged pool - isn't written to the pagefile pre-emptively (i.e. while it's still in working sets). Um, exception: If a process uses FlushViewOfFile on a pagefile-backed section, the pages are written while they're still in the process(es)' working set(s). But that's uncommon, and it's the code in those processes, not the OS, doing it. (n.b.: If any "pre-emptive" writing did happen I would call it "predictive". I'm not sure what it's supposed to be "pre-empting".) – Jamie Hanrahan Apr 18 '16 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.