Why does Windows 7 use the page file when there's free physical RAM?

Question

I am using Windows 7 64 bit with 8G ram. After some use, I feel Windows is getting sluggish. The drive is thrashing. When I look at the resource monitor and disk activity, I see a few instances of use of the page file (c:\pagefile.sys). I check the physical memory and I see about 2.3G available memory and 700M free memroy.

Why doesn't Windows use more of the free memory and less of the page file? Does it need to leave some x amount of free ram, how much would that be? Is it a percentage of physical ram?

My plan is get more ram and an SSD for the main drive. Meanwhile I am suffering from slow performance.

Solution 1

First, don't place your page file on an SSD. While SSDs have gotten better about wear leveling, the page file is written to frequently and it will degrade your SSD much faster than general use.

What a lot of people don't understand is that windows never really has free memory. There's a few MBs which are kept free for burst demands, but otherwise, the difference between active in-use application memory and the total memory is generally consumed by what is known as "standby" memory.

These are memory pages which can be dumped if needed (standby memory is a great, big cache), so from an application standpoint, it's available, but they are not by any means not being used. Usually, they function as disk cache, or a pagefile cache.

Windows' goal is to keep the data most likely to be used in this standby cache, based on usage patterns. To use a contrived example, let's compare the relative value of the private memory of a program like Windows Update (usually configured to run once a week), over the caching the contents of your desktop in this standby memory:

For a good majority of the time, Windows Update is sleeping. It's holding up memory and for the most part, doing absolutely nothing of value with it while it's waiting for the schedule to come around. The contents of your desktop folder on the other hand, might be queried constantly, especially if you like to save files to it.

In this case, what Windows will do is page out the memory allocated to Windows Update (even though memory isn't "full", and use the space made available in RAM to cache the contents of your desktop. This results in better performance for you.

Windows is making thousands of these decisions and managing a disk cache for hundreds of files being constantly written to by background services while trying to balance this with memory demands of active applications. Sometimes it gets it wrong for a moment, and we might have to wait for it to page data back into memory when we switch to an application that's been sleeping in the background for a while. But what you have to think about is if it had kept that application completely in memory, how many other applications would in turn be bogged down waiting for disk writes and reads to complete, or themselves be forced to page out? What if those were applications you were using in the meantime?

---

Applications frequently allocate memory pages which are used very rarely, such as start-up code (used once and then not needed), shut-down code (used once and then not needed), or update code. It's not practical to keep all this in memory when there are much more important uses, so once Windows identifies sections of code that haven't been needed for the current operation of an application, it happily pages out those sections to the pagefile, even if it technically could retain them in memory.

(And actually, depending on the applications, systems might frequently allocate more memory than they actually have, expecting most of it to wind up paged out. If you're looking at a detailed memory breakdown, the "Commit" or "Commit" charge is how much memory Windows has allocated to various applications. The pagefile is used to provide guarantees for this memory, even if it doesn't have enough physical RAM to cover it.)

---

I just noticed you did make a distinction between available and free memory in your question; My apologies if you feel lectured and already knew the difference. Ideally, free memory is always 0. However, while standby memory is memory that can be released, it's not always memory that can be released quickly. If I try to write a 1GB file to disk, windows is going to stick it in a disk cache in memory if it can, and then slowly write it out to the harddrive in the background. If an application needs to request 50MB of additional memory, but none is available because this huge disk cache is still being flushed out, then the application will hang until it's available. Keeping a small buffer on hand allows the system to resolve this issue with minimal lag from the user's standpoint. You might also wind up with larger-than-normal buffers if Windows just emptied part of the standby cache or released a lot of in-use memory, but hasn't filled it with new cache data yet.

Solution 2

It's called planning ahead.

Writing memory pages to the pagefile when there is still plenty of RAM is a good thing. As soon as a program requests more memory than there is free, the OS can start clearing out space as soon as possible. Better to prepare now than later.

If the OS were to wait around, then you run into a performance bottleneck. If a program asks for more memory than is available, now you have to wait until the OS writes out changed memory block, and then free them up.

Solution 3

There is a tool to set the disk-cache by SysInternal.

cacheset.exe

You can find it here:

http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx

Solution 4

I have had page file turned off for the last 7 years. Actually it's the first thing I do after fresh install. Never had any problem with it. (Actually I had one - game called "titan quest" performed a very stupid check at startup so I created a 4 MB pagefile only to make it happy and turned PF back off later). As for the original question. Windows uses our RAM for disk I/O cache. For some reason it thinks the disk cache is equally important to the active programs code and data. And there's no way to limit disk cache size. It's there by design and we can't do anything about it... Oh, wait! We can! Just turn the pagefile off. Running applications that are heavy on RAM? Buy more RAM or close one app before launching another. You can use Process Explorer to see how much memory is used at any given moment. Personally I have 8 GB RAM both at work (vmware + virtualbox + eclipse + firefox + delphi + adobe premiere + skype + more background programs ) and at home (heavy gaming) and can't remember when was the last time I saw the "low on memory" warning.

Solution 5

The arguments (here and here) for keeping and using the page file even if there is enough RAM are:

• Even if there is free memory now, the machine may run out of memory later. Better to drop little used parts of memory to disk in advance.
• There is also "standby" memory that appears as free but is actually used for disk caching. It is also important for performance, better to have some.
• If you run out of RAM with the page file disabled, it is the hard crash.
• While 2, 4, 16 or any other number of Gb of RAM may look like "a lot", this may be not as true as you believe. You need to profile.

With Windows Resource monitor it is possible to see how much RAM is used for caching (shown as "Standby").

If you see that your RAM is actually used or in standby, the page file is useful for you. If the combination of your tasks and available RAM is such that significant part of memory shows up as unused ("Free"), I think there is no need to grind the hard drive just from respect to somebody who "knows better and said so here".

View more solutions

Comments

[Scott Chamberlain]

Just because it is writing/reading to the page file does not mean it us using it, it may just be updating it so it can dump the memory quicker if there is a sudden demand. I recommend running performance monitor or do a deep diagnostic and seeing what is causing the sluggishness.

[kotekzot]

Having more than 8GB of RAM will not increase performance in 99.(9)% of cases. Have you stuffed your mobo full of cheap low frequency/high latency RAM chips? Replacing them would be a better idea than adding more.

[user1984103]

@kotekzot That depends. I've generally found RAM latency to be somewhat negligible in most bottlenecks. If he has enough memory that he's not having to wait for applications to be paged in when he alt-tabs through all of them, then the next biggest bottleneck by several orders of magnitude is almost always the harddrive, and an SSD will fix that right up.

[Tony_Henrich]

@if I have more ram, I can put the page file in a ramdisk which is much faster than HD access. It's a Dell laptop workstation level so I am sure the components are not cheap. I am aware that laptops have slower hard drives and IO subsystsem than desktops.

[Jamie Hanrahan]

Please don't put your page file on a RAMdisk. That will only make the system incur more page faults. Yes, if they're to the pagefile-on-RAMdisk they will be resolved more quickly than if it had gone to a real disk, but not having them at all is still far faster; also, many of the increased page faults will be to mapped files, and those will not be helped by the RAMdisk at all.

[FreeSoftwareServers]

This reminds me of "LinuxAteMyRam" >> linuxatemyram.com , Similar Concept AKA > Its the OS doing what its designed to do to make the most of its resources.

[FrankRuperto]

What a lot of people don't understand is that windows never really has free memory... I don't agree with your statement. If that were the case, Windows would be constantly swapping. Windows does use some memory for disk caching, but on a box with 8GB of memory, you're going to have lots of free memory.

[user1984103]

@FrankComputer See the screenshot I posted for my 8GB work system: 6300MB in-use, 1700MB standby disk/cache, 42MB free. Looking at my home system (32GB memory), you're actually correct, but just at the wrong threshold: 9.2GB in-use, 14.5GB disk cache, 8.6GB free. You'll have free memory if windows has simply run out of things to cache, but that threshold is pretty high. Windows is not constantly swapping because disk cache is not swap space - it's passively cached when files are requested and not in the cache. You don't notice the times that it pulls from the cache and there's no HDD activity.

[FrankRuperto]

That's because Windows detects how much total memory the system has and by default assigns xGB for pagefile.sys and xGB for disk caching, but you can fine-tune these and have more free memory if desired. I have a Vista-SP2 laptop with 2GB memory. Its free memory averages 1GB and my disk light rarely blinks.

[David Schwartz]

@FrankComputer: If your system is performing well, it's not because of the free memory. Free memory is memory the system is not using, and it can have no more effect on performance than memory sitting on your desk. The only way to improve performance with memory is to use it, so if it's free, it's not being used to improve performance. Making more memory free means using less, making performance worse.

[Tony_Henrich]

When getting more RAM, 16G, I am planning to put the page file in a ramdisk.

[user1984103]

@Tony_Henrich Disabling the page file is bad. Very bad. (Moving the pagefile to a ramdisk is effectively the same as disabling it. Windows is unable to move data it doesn't need immediately out of memory). Many programs request memory that they do not immediately need, but might need in the future. Usually, windows allocates this memory on the page file, and it does nothing. For example. MSSQL server allocates 8GB of ram when it starts up. Even for 0 databases. Just because. If you put your pagefile on a ramdisk, you will waste considerable amounts of RAM that could otherwise be used for cache

[user1984103]

@Tony_Henrich Currently, windows is optimally managing your pagefile and your RAM, given how you use your system. The only improvements you can make upon it are such: Add more memory, or move your OS to an SSD. Messing with your pagefile will degrade your overall system performance at best, or affect your system stability at worst.

[Tony_Henrich]

You're explaining what Windows does with memory. If I have lots of free memory then Windows should use it, regardless if an app is sleeping or doing nothing. What's the harm in keeping it in memory when memory is available. Once memory gets low, then Windows can make use if the page file. Using the page file is causing wear and tear on the drive. There's no wear in using memory. Second, I use an SSD for my page file. While SSDs lives are smaller than hard drives and there's wear on then with lots of writing, that still doesn't to a few months. It's still in years.

[Tony_Henrich]

I upgraded my SSD to a larger and faster one on my home computer. Upgrades will happen before an SSD breaks down. SSDs are getting cheaper per SSD, faster and larger. So this frequent argument about their wear is ought to stop at some point because it won't be relevant anymore.

[Tony_Henrich]

With 16G+ and with light programs, the times when a program asks for more memory than what is free is much less than the frequent use of the page file. So for those cases, it's better to use some of the free memory and less of the page file. There's no one solution that fits all cases.

[surfasb]

I don't think you get it. It doesn't have to be one or the other. Windows can write to free memory and write to the pagefile. It isn't like writing to the page file or writing to memory.

[Marcks Thomas]

Windows is quite clever in determining what (not) to put in the page file. With the exception of some almost purely theoretical scenarios, turning it off will harm performance, even with 8 GB of RAM. Even if the correct answer were missing, this is certainly not it.

[a2552308]

Got any evidence to back up your "harm performance" claim? I present an MS article support.microsoft.com/kb/889654

[a2552308]

Simply put: page files can only increase disk activity... and windows isn't smart enough to not use it at all if it has lots of RAM. On an SSD system this may not be too noticable, on a spindle system this may affect application performance a lot. Refer original poster.

[Marcks Thomas]

Windows isn't 'smart enough not to use it all' because it is not beneficient not to use the page file, even when enough RAM is available. This is what Microsoft has to say on the subject. Here is a more in-depth article about the pagefile myth. To fully appreciate how smart Windows actually is, I refer you to this blog.

[a2552308]

It would be nice if the OP could disable it and report back, but given the timing that probably isn't going to happen. I run many applications on a system that I never turn off. I usually have at least 20 applications open at any one time and I always expect to be able to switch to another application at any time and have it respond immediately. This isn't possible when running a page file because Windows will always swap out pages that haven't been active for a while. Many people may not notice the difference because of the way they work, but I do, and page files make the way I work slower

[a2552308]

Relevant section from MS article: "However, as more RAM is added to a computer, the need for a page file decreases. If you have enough RAM installed in your computer, you may not require a page file at all, unless one is required by a specific application." I couldn't find the relevant sections from the many articles you linked, maybe you could quote the relevant sections?

[Marcks Thomas]

"I always expect to be able to switch [...] and have it respond immediately. This isn't possible when running a page file because Windows will always swap out pages that haven't been active for a while". This is false. Windows will make a copy to the page file so it can immediately clear out used RAM when it is needed for other applications. If the paged data is read and still available in RAM, it will be read from there, no slower than without a pagefile.

[a2552308]

Sounds good in theory, not what I have observed in practice though.

[bart]

Darth Android, this is the clearest, most succinct explanation I have read explaining why a page file is highly recommended and why memory use in modern operating systems is so much more complicated than the Task Manager would have you believe. I wish more software developers understood these fundamentals, let alone average users.

[Calmarius]

At our company our computers have 24GB RAM (because sometimes we are using lot of virtual machine images simultaneously). But Windows still thrashing a lot even if none of them running. Our HDDs constantly rattling. But task manager shows that only 4G is used from the 24GB... Something must be wrong with Windows' virtual memory manager. Conversely Linux doesn't use any pagefile if plenty of RAM available, and it's more responsive than Windows.

[user1984103]

@Calmarius Are you sure that's because of the page file? Have you looked at Windows' Performance Monitor (Task Manager > Performance > Performance Monitor) and looked at what files are actually being used when the disk is thrashing?

[Calmarius]

@DarthAndroid Well, not. The problem is that Windows tries to read and write 50-100 files simultaneously all time. So the disk head need to seek continuously... The System continuously doing disk I/O with at least 1MB/sec.

[user1984103]

@Calmarius Make sure write buffering is turned on for the disk (i.e., it's an internal IDE or SATA disk, or manually turn it on in the drive properties). Otherwise not much you can do if it's constantly writing to files and reading new ones. Unless you have ~15+ GB of standby memory already, the page file probably isn't having any effect yet.

[Didier A.]

I maybe support your answer. The thing that we need to know, and which I don't, is does Windows assume that the amount of RAM in your PC is there because your usage requires it? If Windows plans based on the amount of RAM, it could assume that even though 16gig is present, the user will be running for 16gig worth of proceses, so normal swapping and caching behaviour should still be used. Where as this isn't always true. Some people have 16gig, but really they only will ever need for 8gig max. It's almost like Windows should consider the extra 8gig as super fast swap space.

[Didier A.]

Imagine my running processes used an average of 4gig of RAM, those running processes are reading up to 4gig of I/O that can be easilly predicted and I have a 128gig SSD on which resides my OS, files and page file. Say I have 32gig of RAM. It seems Windows would choose to have 4gig for active process memory and pretty much everything else as disk cache, about 28gig. While all inactive process memory would go to the page file. Given this scenario, if I open a sleeping process, it will page fault a lot. Putting swap in RAM would make those fault instant. In this case, I'd rather not cache disk.

[user1984103]

@didibus If you want to put swap in RAM, then just disable swap, it's the same thing; That said, if you wake up the sleeping process frequently, then it won't get paged out; if you don't wake the sleeping process frequently, then who cares if it gets paged out? No automatic memory manager will be perfect; the goal is just to get it as best as possible. I'd rather have it be optimal 90% of the time and sub-optimal 10% of the time than the other way around. The problem is you'll only notice the sub optimal stuff, never the optimal stuff.

[Didier A.]

@DarthAndroid Ya, probably easier also to disable Swap. My point was that if you have extra RAM, but you do not need it for the amount of concurrent active processes + their potential disk IO, then the extra RAM can be viewed as simply a very fast page file, which is always better then using a HDD for swap. Arguably, the extra RAM is worthless, unless you use it for SWAP. 28gig of disk cache is overkill. It would be better to simply keep all processes that I've opened but never manually closed in there, even if they went to sleep, I am more likely to use them again than use a non obvious file.

[Didier A.]

@DarthAndroid To directly address your comment: If I infrequently wake up the sleeping process, it still means that I do wake it up sometimes. Say I open outlook, never close it, but only check it every morning. It will be swapped out. But why? I have 28gig free, 4 gig active process using an average of 4 gig IO. I only need 4 gig IO cache for my active processes. So I feel it's better to use that 28gig to cache my outlook, etc., then to start caching more and more IO. I.E., when you have surplus RAM, use it as SWAP, instead of even more disk cache.

[Didier A.]

@DarthAndroid I'm commenting a lot, sorry. The reason I say all this, is because it seems Windows assume you buy the amount of RAM you need for Active Processes. This is normally the case, since why would you pay for more RAM, when you don't need it. But recently, RAM has gone down, and some people are just adding RAM for fun. Which the memory manager does not take into account. It sees 32gig RAM and think you might be using most of it for concurrent active process, so it optimises for that. Some people get 32GIG just cause, in which case, disabling swap will make it even faster.

[user1984103]

@didibus Windows does not assume that, no. Windows assumes very much the opposite of that. So much so, that there is no way to disable the disk cache (something you can do on Linux and OS X). Windows works best with at least 2-4GB of memory not in use by active processes (and available to the disk cache), with a page file available (which should be 1-2 times the size of memory in the machine). I have 32GiB of RAM in my home desktop, only 16GiB of which is used by active processes. The disk cache eventually fills the other 16GiB - so it is being fully, properly utilized by Windows.

[user1984103]

Sorry, I missed your first 2 comments in that block; To use your example, Windows will only page out Outlook to make room for the "non obvious file" if it has already determined that you're using the "non obvious file" more than you're using Outlook. It doesn't segregate process memory from disk cache. It just looks at everything as a whole and says "Alright, between all the files on disk, and all the process memory, what is most likely to be needed next?" and then moves the answer to that into RAM (active process memory + disk cache), and moves everything else to disk (pagefile + filesystem)

[user1984103]

The other thing to keep in mind is that it doesn't have to page out "all of Outlook". It's possible to page out only the parts of Outlook that you aren't using. For example, right now 7% of Outlook on my system is paged out because it's not being used. TL;DR: Surplus RAM is used as swap or disk cache, whichever your usage patterns benefit best from.

[Didier A.]

@DarthAndroid But everything still shows that Windows will page out to disk some stuff no matter what. My point is, some people have so much extra RAM, if they disable SWAP, they will never run out of RAM, ever. They'll even have enough RAM left for proper disk caching. In those cases, Windows will run faster with swap disabled. And I explain why by comparing the extra RAM to a really fast HDD for your swap. Also, I'm not sure about this:"Alright, between all the files on disk, and all the process memory, what is most likely to be needed next?" You have source?

[user1984103]

@didibus What do you mean by "run out of RAM"? My systems are always sitting at 95% utilization of ram (active memory + disk cache) or higher, which means the system will benefit from more memory. It's true that the more RAM you have, the less of a difference that more RAM will make (and thus, less of a difference that it will make if you disable the page file and give the system less RAM, effectively), but at no point is the statement "Windows will run faster with swap disabled" true. Windows Paging Algorithm Summary.

[Didier A.]

@DarthAndroid I mean run out of RAM for what RAM is originally meant for: transient memory. As you said, Windows also uses RAM as a cache for disk I/O. But Windows also take transient process memory that it feels are likely not to be used in a while, and store them in swap on disk. It does this preemptively, in case you suddenly require more RAM, it has already swapped out the old stuff and can store the new one. But if you have so much RAM, that this will never be an issue, it's not helping in any way, it's simply moving transient memory into a slower storage, which simply makes things slower

[Didier A.]

@DarthAndroid So with extra RAM to spare, the argument becomes, what should I use my extra fast storage space for? Disk cache or rarely used process code + memory? And I think there's a point where caching more and more of your disk files into RAM does not improve performance. Because you've got to ask yourself, is this file more likely to be randomly accessed then this process + it's memory? Off course, that depends on your usage, but I'd argue a process I started and stopped using is more likely to be used again then a file I've never accessed.

[Didier A.]

@DarthAndroid The preemptive nature of Windows storing rarely used process code + memory into swap to make room for disk cache and the possibility of you launching one more process which could require free ram, is basically what my argument boils down to. Windows assume this is required because it thinks you might not have enough RAM for all your process needs. So, I might be wrong about this, and maybe Windows deals with it in a very smart way I'm unaware of, so please tell me if you have more details of this.

[user1984103]

@didibus Windows generally doesn't cache files you've never accessed (With the exception of SuperFetch, which is limited in how much RAM it'll use, and can be turned off). It's not rarely used process code vs. a file you've never accessed; it's rarely used process code vs. a file you've already accessed at least once. Windows doesn't make assumptions - It knows exactly how much RAM you need at any given point, and exactly how much you have, and re-evaluates this every time it needs to allocate more.

[user1984103]

Even though Windows writes to the page file all the time, you will not see it loading data from the page file until Active+Diskcache takes up all of RAM. When that happens, Windows simply looks at all of RAM and says "Alright, I need 4KB more of memory, which page is lowest-priority that I can kick out to make room?" It doesn't care about whether it's active memory or disk cache, lower-priority is lower-priority. If you're using the disk extensively, then most of the disk cache will likely be higher-priority than rarely-used process memory.

[Didier A.]

@DarthAndroid Good to know that, I didn't. But I still find issue with the fact that it prioritizes caching disk over caching old process. Unless I understand this wrong. In the end, everything is data, but I feel process code is more important data, that needs to be fast to load. Where-as I/O, like files that the process modify or read through during execution isn't as high priority for me. I would prefer it to be Active + Inactive Process + Disk Cache, in that order. So when RAM is low, you start eating away at Disk Cache first, then Inactive Process. Ideally a 80-20 proportion.

[Didier A.]

@DarthAndroid Which is what I feel happens when we disable SWAP. It forces Windows to get rid of Disk Cache in lieu of Inactive Processes. I understand low and high priority, but I feel the user experience of a process loading up, versus a process loading a file is a worst experience. I'd rather wait for Word Doc to open or save, then wait for Word to restore itself.

[binki]

But by trying to plan ahead, isn’t Windows potentially filling the HDD’s/SDD’s on-chip cache—making concurrent file writing/loading operations slower? This pre-swapping of RAM does sound like a good idea, but it seems like it incidentally puts load on the system at bad times.

[binki]

And since time has passed, 8GB is no longer enough anymore…

[Jamie Hanrahan]

"Simply put: page files can only increase disk activity..." This is a highly simplistic view. Reality is that disabling the pagefile doesn't turn off virtual memory, and if you don't have a pagefile, Windows will simply do more paging to and from other files.

[Jamie Hanrahan]

@DarthAndroid : Your claim that some standby RAM cannot always be released quickly is not correct. Although Windows does do write-behind cacheing of file writes, and although part of standby RAM is used for proactive file cacheing (by SuperFetch), standby RAM is not used for write-behind cacheing. Rather the data is written either a) directly from whatever buffers the application put it in, or b) from pages belong to the file cache's working set. Either way those pages will not be on the standby page list.

[Jamie Hanrahan]

@didibus : No, disabling the pagefile does not "get rid of disk cache". It forces Windows to do MORE paging to mapped files (which includes the stuff held by the file cache).

[Didier A.]

@JamieHanrahan Not following you. Are you saying the page file is only used for application code, and a separate part of my disk is caching files?

[Jamie Hanrahan]

@didibus No. The pagefile is never* used for code, because code is never* changed once paged in. If a page of code is dropped it can be paged in from the exe or dll or etc. it came from originally. File cacheing doesn't use the disk. There are two file caches in Windows: The origional file cache (been there since NT 3.1) is reactive; it uses RAM that belongs to a system-wide working set, not the standby list. SuperFetch (Vista and later) is proactive, using pages on the standby page list that have been there and not accessed for a long time. Neither involves the pagefile. (*almost)

[Didier A.]

@JamieHanrahan This is my current view of it. The pagefile is used as extra RAM when RAM is running low and applications need to store more temporary data then RAM allows. SuperFetch is used to cache file IO to RAM to speed up IO when applications request it. Both are proactive. RAM is copied to the pagefile even when RAM is not maxed out, just in case it would be eventually. SuperFetch fills up the free RAM to cache disk even for things you are not currently using. It still looks to me that the pagefile only slows down IO given a use case where you never max out RAM.

[Didier A.]

@JamieHanrahan Now, the only thing that makes me question that, is that it's possible that by paging some active processes that Windows believe to be less likely to be used again then an inactive process that I often start at the current time of day, it would decide to page the active process and instead use the RAM to cache the inactive process Windows believe I'm more likely to open next. The thing is, I feel, a perceived longer time on application start annoys users less than an app switch to an already running process being slow. Why I think some people say disabling pagefile boosts perf.

[Jamie Hanrahan]

@didibus Pagefile writes are reactive, never proactive: the modified page writer thread (which is what performs writes to the pagefile) never writes anything that isn't already on the modified page list, and nothing is on the MPL that hasn't been pushed out of a working set (due to memory pressure) to make room for something that's being paged in. Nor does Windows make predictions as to "inactive process Windows believes you're likely to open next". When you switch to a long-idle process, stuff from that process is paged in on demand, as necessary, as and when the code touches it.

[Jamie Hanrahan]

@didibus Maybe you're thinking of SuperFetch? It does bring in exe and dll files that you've used recently, in case you need them again soon. (That isn't an "inactive process", it's just files at that point.) But SF doesn't involve the pagefile. SF uses RAM that is already on the standby page list; nothing will ever be paged out to make room for something SF wants to bring in. SF does not even decrease the amount of "available" RAM as the pages it uses stay on the SPL and so remain part of "available"; it takes no more time to use them for something else than if SF hadn't used them.

[Didier A.]

@JamieHanrahan Are you sure Windows is reactive with the pagefile? I'm pretty sure every info I read mention that Windows will preemptively page out long idle processes even if it doesn't need the RAM in anticipation of needing the RAM.

[Jamie Hanrahan]

@didibus That's called working set trimming. It doesn't happen unless the system is extremely short on RAM, or the overall page fault rate is too high, or all of a processes' threads have been idle for a long time. This is reactive, not proactive. Note that this happens even if you don't have a pagefile (not all pageable pages are backed by the pagefile) so getting rid of the pagefile won't stop it.

[Jamie Hanrahan]

Getting rid of the pagefile will not turn off disk caching.

[Anton Duzenko]

Jamie, well, duh

[Jamie Hanrahan]

You wrote: "[Disk cacheing] is there by design and we can't do anything about it. Oh wait! We can! Just turn the pagefile off." Well, turning the pagefile off doesn't do anyting about disk cacheing, so what are you saying? It's a stupid idea anyway, as it forces the OS to keep all private commit in RAM forever once it's been touched. This makes less room for mapped virtual memory (like code), so that stuff has to be paged more. The proactive disk cache (superfetch) uses what's left over after all of the above, so it doesn't increase paging of either.

[Anton Duzenko]

Sorry, did you invite me to "your idea is stupid" contest? I am too old to qualify. I might want to discuss the disk cache and pagefile but I doubt you're interested in what I have to say

[Jamie Hanrahan]

I never said (or thought) that turning off the pagefile was your idea, so I wasn't saying anything about "your idea". Oh, while I"m here: "For some reason [Windows] thinks the disk cache is equally important to the active programs code and data" is flatly wrong. Superfetch only uses pages that are on the Standby list and hence already part of "available" RAM; it does not take pages from programs' code and data. And those pages remain available, i.e. immediately available for programs' code and data, even after they contain cached data from files.

[Anton Duzenko]

Are you trying to say that Windows does not page out programs as long as there is some memory available? Do you have any proof? How about your version of when exactly it actually starts paging out programs?

[Jamie Hanrahan]

I'm not saying anything of the sort. (Where are you getting this?) I am saying, though, that Windows never pages anything out to make room for disk cache. On the contrary, the cache uses pages that are not currently parts of processes and would therefore otherwise be wasted. Such RAM remains immediately available to code and data that needs it for paging stuff in, so it is not "used up" by the cache, merely "borrowed". So the cache does not reduce the amount of code and data that can be paged into, or kept in, RAM. Ref: Windows Internals by Solomon, Russinovich, and Ionescu.

[Anton Duzenko]

Why did you choose me to argue? Please scroll up to the most voted answer by Darth Android that explicitly asserts that windows does page out programs in favor of the disk cache and write your comments there

[Jamie Hanrahan]

I've already replied in DA's answer. But what you just said isn't what he said. He said that Windows will page out long-inactive processes (true). And he also said that the disk cache might use the pages freed thereby (also true). But that doesn't mean the disk cache is necessarily taking precedence. The disk cache only uses those pages if nothing else of higher priority needs them. A huge amount of testing has demonstrated that this is a good tradeoff.

[Anton Duzenko]

Define "long-inactive". In seconds, please

[Jamie Hanrahan]

The basic time is 15 seconds: a thread that's been in a wait that a) was entered from user mode b) more than 15 s ago can have its kernel stack made pageable, IF the overall system pagefault rate is high or if the free page list is too small. If that's been done to every thread in a process, then the entire process may be forced out of RAM. btw, removing the pagefile only prevents page-out of pagefile-backed pages (and they are still lost from the process, they will just sit on the modified page list). Even without a pagefile, pages backed by mapped files can and will be dropped from RAM.

[Anton Duzenko]

Sorry, I don't see how all that proves me wrong. Less paging is better than more paging, period.

[Jamie Hanrahan]

The amount of paging done is not dependent on whether you have a pagefile. It's dependent on how much RAM you have and how much virtual address space is being actively referenced. If the latter is larger than the former it's going to page the remainder to and from disk, with or without a pagefile. Getting rid of the pagefile just forces Windows to page only mapped file contents to disk, keeping all pagefile-backed stuff in RAM, no matter how stale it is. In other words you're forcing Windows to keep some older, staler stuff around in favor of some stuff that's been used more recently.

[Anton Duzenko]

Please don't throw self-contradicting statements at me. Either it keeps stuff in RAM or not, please choose one and then come back

[Jamie Hanrahan]

Whether it keeps any particular stuff in RAM or not is dependent on many things, several of which we haven't touched on. If we had, I doubt you'd find it self-contradictory, but there is a limit to what can be covered in Q & A 600 chars at a time. I can tell you quickly, though, that without a pagefile some stuff will still be dropped from RAM, and other stuff will be kept in RAM but even so will need page faults to get to. (Have you noticed that even without a pagefile, your fault rate and hard fault rate are both nonzero?) Read the memory management chapter of Windows Internals, 6th ed.

[Mooing Duck]

@binki: Yes, it does interfere with disk read/write times, but if I recall, they're using a lower priority, so other read-writes should go first in general.

[David Schwartz]

@a2552308 Imagine if your memory is mostly full with dirty pages that will never be read again. With no page file, only the remaining memory can be used for clean pages, and if the working set of clean pages exceeds that memory, you'll have hard page faults like crazy. With a page file, you can get those dirty pages out of RAM, allowing more clean pages to stay in memory, reducing disk I/O.

[Joshua]

@Anton Duzenko: Not having a page file forces Windows to not page applications to disk. It is conceivable there is a workload for which this is faster than having a pagefile.

[Kotauskas]

Someone likes crashing a lot. I don't, so I set a 8 GB page with 8 GB RAM because I play Minecraft.

[mirh]

The premise of this answer is stupid. As per Microsoft's metrics, there's hardly a better file to put on an SSD.