5

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?

speeder
  • 380
  • 4
  • 19
  • 1
    update to Windows 10: http://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 04:16
  • No, not really. If it's written to the pagefile it's already out of the working set of the process it came from. I'm not sure where this notion came from. Personally I think it got started because Windows XP mislabeled the "commit charge" graph in task manager as "PF usage", leading people to think a lot of pagefile usage was happening when it wasn't. What does the perfmon counter for pagefile usage tell you? – Jamie Hanrahan Apr 18 '16 at 08:54
  • 6gb of commit charge, 4gb "active", 2gb of "standby" on RAM, and perfmon says there is 4gb of "standby" on pagefile usage. – speeder Apr 18 '16 at 12:36
  • If I use RamMap to zero the entire ram except active memory, I/O immediately goes to 100% as windows copy lots of stuff I am not using to "standby" physical RAM, this doesn't increase commit charge, after the RAM is full, the I/O goes lower, but activity keeps going on for a while, with pagefile usage "standby" and "modified" slowly increasing, after about 10 minutes in total it stops. – speeder Apr 18 '16 at 12:38
  • I don't know where you look to find "4 GB of "standby" on pagefile usage". There is no such counter as "standby on pagefile". The pagefile usage counter is in percentage, not bytes, and there is no fixed relationship between it and the standby list size - some of the stuff on the standby list will be in the pagefile, but some (the stuff that is backed by other files) will not be. Conversely, some of the stuff in the pagefile will be on the standby list, and some will be nowhere in RAM (the RAM it came from having been repurposed after it wasn't referenced for a while). – Jamie Hanrahan Apr 21 '16 at 05:22
  • @speeder Also, I see no command in RAMmap to zero anything. "Emptying" is not writing zeroes. – Jamie Hanrahan Apr 21 '16 at 05:45
  • Jamie Hanrahan I used the term "zero" because after you use the command, it shows the freed memory as "zeroed" instead of "available" or something like that. – speeder Apr 21 '16 at 12:39
  • Ah, standby on pagefile I saw on Process Explorer, when viewing performance info or something like that the name of the dialog box. – speeder Apr 21 '16 at 12:40

3 Answers3

3

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.

speeder
  • 380
  • 4
  • 19
1

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.

David Schwartz
  • 61,528
  • 7
  • 100
  • 149
  • 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 08: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
  • Found a GREAT post explaining what I mean by the preemptive paging that cause unecessary I/O, please read this: http://serverfault.com/a/23684/51741 – speeder May 20 '16 at 03:37
1

Sadly you cannot do this, you basically can either have a pagefile, or not have one, you can choose where the pagefile is stored and how big it is, but you have no control over the algorithm of what gets swapped out.

I am sure you have had frustrating answers given to you as if you are an idiot and the Microsoft developers are always correct etc.

Basically windows is programmed to prefer standby memory (read cache) over keeping things out of the pagefile. The idea been that there is a chance you want to read data that is in the standby chache, and if that happens, you have a performance gain.

I dont quite agree with this, my opinion is, if you swapping live data out to a pagefile, it is "inevitable" your system will want to read that data at some point, and when it does, you will get lag, because its been read from the pagefile. In addition reads from page files have higher overheads vs reads directly from a filesystem.

On my system as an example windows will always page out Nvidia multi display power saver tool, I dont know why, something in the algorithm makes it pick on that app, it will get pages out even if ram utilisation is as low as 5%.

My opinion is that page files should only be used as disaster avoidance, basically akin to the swappiness=1 linux sysctl. Which is basically the same as what you were asking in your question essentially the only parts of ram usage in windows that are are important is "in use" and "modified", modified is the write cache, which obviously needs to dump its data to disk before it can be cleared, whilst clearing standby cache has no negative consequences.

I have done a fair amount of testing on my 32 gig windows system, and I have seen absolutely no evidence of performance gain from having the page file enabled, but I have seen performance loss as trying to use any app it chooses to page out suffers lag.

The clear answer I give to which way to go question, is if system stability is your prime aim, keep the page file enabled, and have it set to at least 8 gig in size. If performance is your goal, and especially if you have at least 32 gig of ram, then by all means disable the page file.

Chris C
  • 51
  • 2