One way to see how the RAM is being used in the Windows 7 system, is with the program RAMMap.
Click for full size
You can see here that even with 32GB, a ridiculous amount of memory, that it all pretty much gets used up by the system too. In this here, about 4GB is in active use for all the stuff running, and the rest of it is filled with files in the cache. The file cache, or referred to as the system cache, or here it is known as the standby list.
Things in the standby list will be thrown out of RAM (deallocated) whenever more space is needed for other stuff. I will say there have been times when the cache deallocation has seemed slow, as if it was releasing in tiny amounts. Some updates of Windows 7 changed that, and it is better behaved after these updates.
RAMMap can also be used to clear these caches, and working sets and other stuff. RAMMap can manually clear out stuff in the cache, and it can manually clear stuff that should not be cleared, which will have to be loaded back in again (look in the empty menu item). You must refresh RAMMap's display manually to see it change.
RAMMap can also show you every file that is in all these different places, and lots of other data.
A more simple and built in way to see the brunt of the information is by using the resource monitor, and going to the Memory tab, where you get a view like this. (resmon.exe)
You can see this standby quantity at the bottom, which is just using the RAM for file cache, all still considered to be available memory, if needed for other purposes. See also the quantity they call available.
I am not going to say that the system is all perfectly using the RAM exactly the way every person would want to have used it, but it generally (at least) has some purpose behind what it is doing :-)
Win7 survives well on about 4GB of RAM, would be very happy in most uses with 8G, the rest will get used, but unless you have a great need, or run programs with a great need for it, you are not dying without it. Usually, people who really need more than the 4-8GB know why they do it.
Disabling paging:
I am not going to disagree or agree one way or another with any user's choice to disable paging. I ran that way myself at times. I will indicate a few things both learned from Windows makers, and learned the hard way.
1) There is no great need with large memory of today's computers to have the paging be 1x or 1.5x of the total memory. An adequate amount of paging, will be an adequate amount. If you have 16GB of memory, you surely do not need 24GB of paging. Exception, I think there are some Full Dumps that the full paging size is needed.
2) There are many programs in existence that will fail with errors that are very poorly described, when there is no set paging amount at all. Because of that, having at least a small 512MB space available for paging to disk can keep these programs from tossing up an error. So myself even after having run at various times without paging, I have a little one there anyway, because I am not giving any program another reason to error on me.
Yes, the system will end up using it (still) in ways that some users might find undesirable, generally only for unloading junk that you will not be using. I would agree with what people say about it on both sides, the program errors are a reason to keep it regardless.
Best Answer
First, it is a giant mistake (not yours) that Windows' dialog, the one where you set the pagefile size, equates the pagefile with "virtual memory." The pagefile is merely the backing store for one category of virtual address space, that used by private committed memory. There is virtual address space that is backed by other files (mapped files), and there is v.a.s. that is always nonpageable and so stays in RAM at all times. But it's all "virtual memory" in that, at least, translation from virtual to RAM addresses is always at work.
Your observation is correct: Windows' allocation of pagefile size uses a simple calculation of default = RAM size and maximum = twice that. (It used to be 1.5x and 3x.) They have to set it to something, and these factors provide a result that's almost always enough. It also guarantees enough pagefile space to catch a memory dump if the system crashes (assuming you've enabled kernel or full dumps).
Ah... it starts out with the "initial size". This is NOT the "minimum allowed". So that is why you are seeing it at your RAM size, because Windows uses that for the initial size.
But... are you saying you are seeing the actual pagefile size go to the maximum setting? e.g. if it is set to 16 GB initial, 32 GB max, you're seeing the actual size ("currently allocated") at 32 GB? It should always revert to the initial size when you reboot, btw.
Do you see "system is running low on virtual memory" pop-ups? 'cause you should, when the OS expands the pagefile beyond the current size.
The OS is not going to enlarge the pagefile unless something has actually tried to allocate so much private committed memory that it needs the enlarged pagefile space to store the stuff. But, maybe something has. Take a look at Task Manager's Processes tab. The "Commit size" column shows this for each process. Click on the column heading to see who the hog is. :)
This has to do not with available RAM but with something called "commit charge" and "commit limit". The "commit limit" is the sum of (RAM - nonpageable virtual memory) + current pagefile size. (Not free RAM, just RAM.) So a system with say 8 GB RAM and 16 GB current pagefile would have a commit limit of about 24 GB ("about" because the RAM that holds nonpageable contents does not count toward the commit limit).
The "commit charge" is how much private address space currently exists in the system. This has to be less than the commit limit, otherwise the system cannot guarantee that the stuff has a place to be.
On task manager's Performance tab you can see these two numbers with the legend "Commit (GB)". e.g. I'm looking at a machine that says "Commit (GB) 1/15". That's 1 GB current commit charge out of 15 GB limit.
If a program like 7zip tries to do e.g. a VirtualAlloc of size > the (commitLimit - commitCharge), i.e. greater than the "remaining" commit limit, then if the OS can't expand the pagefile to make the commit limit big enough, the allocation request fails. That's what you're seeing happening. (Windows actually has no error message for "low on physical memory", not for user mode access! Only for virtual.)
It has nothing to do with free RAM, as all RAM (minus the tiny bit that's nonpageable) counts toward the commit limit whether it is currently free or not.
It's confusing because when you look at the system after one of these allocation failures, there is nothing apparently wrong - you look at the system, your commit charge is well below the limit, you may even have a lot of free RAM. You'd have to know how much private committed memory the program had been trying to allocate in order to see what the problem was. And most programs won't tell you.
Sounds to me like 7zip is being far too aggressive at trying to allocate v.a.s., maybe it is scaling its requests based on your RAM size? Are you sure there is no smaller pagefile setting where 7zip would be happy? Are you using the 32-bit or 64-bit version of 7-zip? Using the 32-bit version would fix this, since it can't possibly use more than 2 or maybe 3 GB of virtual address space. Of course it might not be as fast on huge datasets.
Well, no, not really. Simply putting a pagefile out there of whatever size does not mean the system will actually be writing that much to the pagefile. (Unless you have the option set to "clear pagefile on shutdown", and even then I don't think it writes the whole thing; the Mm knows what blocks are in use and should only write those... I've never thought of that before; I'll have to check.)
If you want to look at how much stuff is really in your pagefile, use the PerfMon utility. There is a counter group for Page file, and you of course want the "% usage" counter. Interpret this percentage per the file's actual size (as shown in Explorer).
It DOES use a lot of space and since space on an SSD is pretty dear, this is a concern for most of us. One thing you might try is putting a reasonable-sized pagefile, say 4 or 8 GB, on your SSD, then attach a spinning rust drive and put a large pagefile on that. Or if you want an SSD and nothing else for your pagefile, buy a cheap small one just for the second pagefile.