Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have disabled the page file in my system (hard disk is too slow, cannot buy a new one right away, cannot move page file to another partition). When I see into Resource Monitor, using memory demanding applications, the system shows that commit charge is almost 100% full. Indeed, if I keep on demanding more memory, programs start to crash as commit charge effectively reaches 100%.

In the meanwhile, the system says I'm using just 50-60% physical memory and have around 1GB memory available (free + standby).

If commit charge is the total memory actually requested, why does the system says so much memory is free? Is the physical memory being unused by Windows? Is the memory graph wrong? Am I missing something?

Commit charge graph vs Physical memory graph Task manager

share|improve this question
Upload images to imgur and post links here, someone can add them to your post. – Karan Oct 2 '12 at 23:54
Another good answer on the topic is here: – cnst May 21 '15 at 1:57
@cnst Very good article. It helped me understand way better this issue. Why don't you post it as a response? – Jason Oviedo May 22 '15 at 5:59
up vote 11 down vote accepted

Neither the commit limit nor the commit charge are related to free or available RAM.

The commit limit = current pagefile size + RAM size - RAM permanently allocated to nonpageable memory.

Since you have no page file, the commit limit is smaller than it would be if you had a page file. It doesn't matter how much of the RAM is free.

Commit charge is a count of virtual memory, not physical. Suppose I VirtualAlloc 2 GB committed, but then I only access .5 GB of it. The remaining 1.5 GB never gets faulted in, never gets assigned to RAM, so RAM usage does not reflect the 2 GB, only .5 GB. Still, "system commit" has 2 GB added to it because the system has "committed" that there WILL be a place to hold my 2 GB, should i actually need it all.

share|improve this answer
Specifically, before Windows will allocate memory it wants to be able to guarantee that it can fulfill these allocations when they are used. Even if the allocations are not fully used Windows will refuse to allocate more if it can't make that guarantee. A page file, whether used or not, provides additional backing storage. – Bob Jul 23 '14 at 6:00

As the memory allocation test in the article at illustrates, Windows is a type of system that would fail a large memory allocation if such allocation, together with all the prior allocations (the concept Microsoft calls as "commit"), would bring the total "commit" above the sum of both the physical memory and the sum of all the page files (swap).

Consider that an allocation by itself doesn't use any actual memory (neither physical nor swap), prior to a read or write taking place within the virtual address space of the process for the aforementioned allocation. E.g. a 2GB allocation by itself would only affect the "Commit" numbers (in Windows 7 talk), leaving "Physical Memory" alone (until read/write within the said allocation happens).

As far as OS design goes, the alternative approach would be to always allow allocation of any size (unless the available memory is already completely exhausted), and then let the applications fail on read/write instead. See for more details.

share|improve this answer
Yes. The argument for Windows' approach: it is reasonable to expect programmers to check status of a malloc (or, in Win32, VirtualAlloc). Once that call succeeds the program can trust that the v.a.s. allocated is usable and will remain so until a corresponding free or VirtualFree. The other way, ordinary memory reads and writes (i.e. dereferencing of pointers) can raise memory access exceptions. But no programmer expects to have to check status after every pointer dereference. They don't return a status anyway, so it would have to be done with an exception handler. Ugly. – Jamie Hanrahan Jun 18 '15 at 17:48

The available memory is not what you think it would be. It not unused it really a file cache of recently terminated processes or trimed processes that have been force to give up some memory to other processes. They could be called back to there original purpose. see for more detail.

As to not have a page file this is very bad. Windows degradeS poorly without one. Remember even executable files are used as swap files when there is no page file. Even if the drive is slow it better to have a page file until you get up to 8 to 16 gigs of memory. Some people think Even windows 7 can run without one then.

I regularly give old machine a boost by doing a few things. Clean up the hard drive as much as possible. Copy anything you can temporarily remover from the drive onto a backup. Remove applications you don't need. Remove apps can reinstall.

When all that is done defragment your hard disk. At that point recreate your page file. It will be the closest to the front of the drive as is possible. Create a fixed size about 1.5 times memory. Thats my rule, usually I have seen sizes between 1 and 3 time memory. This will give it a slight boost in speed over the usual places it would be placed.

I use the auslogic defrager it's free (ads for more tool though). There are other that do this too. Check out the defragers at It optimizes the disk by placeing recently accessed files near the front of the drive for faster access. It shows where the page file is placed so you can see if you moved it to the top 25% of the drive.

After that reinstall apps and copy back your data.

I would say you get 10 or 20% boost. But the main value is a lot of the hesitation goes away for a smoother experience.

share|improve this answer
Using some testing, it's clear for me that when disk is too slow, not having a page file does indeed speed up the system. I can tell a difference of many seconds in simple tasks as app switching. – Jason Oviedo Oct 25 '12 at 20:53
@Mark You're mistaken. The vast majority of Windows systems run with a pagefile (because that is how Windows runs by default, for good and sufficient reason) and almost all of them use similar-speed disks. And almost none of them show any such problems. The problem is not "the pagefile", it's that you don't have enough RAM. Please note that getting rid of the pagefile does not eliminate paging to and from disk - it merely eliminates one of typically hundreds of files that are commonly involved in paging. – Jamie Hanrahan Jul 28 '15 at 22:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .