这也是很多朋友关注的问题：即然我们的电脑有4G，8G的内存。任务管理器显示可能还有2~3个G的可用内存，但为什么 又要用虚拟内存文件PAGEFILE.SYS呢，还不如将PAGEFILE.SYS文件减少或去掉，直接全用物理内存，那性能不就能提高很多？

这。。。。不是这么简单的。。。。涉及到WINDOWS对内存的管理方式，物理内存，虚拟内存，提交内集交织在一起。。。

下面这个文章说明了一切，基本结论是：不要自作聪明的设置PAGEFILE.SYS文件大小。。。

http://www.overclock.net/t/1193401/why-it-is-bad-to-store-the-page-file-on-a-ram-disk

Hey All
I've seen this recommendation time and time again and I for one do not care for it really. I think this topic could have the potential to spark much debate, but I am going to have a vain attempt at explaining why it is actually counter intuitive to place your page file on a RAM disk, or other virtual storage device that creates a backing store using RAM.
The first thing we need to understand when explaining this issue is how Windows manages memory. You need to know that programs do not directly access your physical memory sticks. The Windows memory manager works closely with the CPU to provide what is called "virtual memory". This essentially gives each process (including paged-pool drivers) on your system their own virtual address space in which to play in. This virtual memory abstraction is in place because it means we don't actually have to worry about how much physical memory is installed on the system (you'll see how the page file comes into play with this shortly).
For 32-bit Windows the default address space for user-mode applications is 2GB. The Windows kernel itself fits into the remaining 2GB. For 64-bit Windows the default address space for user-mode applications is 8TB and the kernel has 8TB also. (Note: This is a simplified explanation).
Because the point of this thread is to not explain how virtual memory works, but rather why you shouldn't place your page file on a RAM disk, I will only quickly iterate some underpinnings about virtual memory: When a program allocates or uses virtual memory from its address space, the Windows memory manager maintains a look up table (and the CPU copies it with what is called the translation look-aside buffer, or TLB) of virtual addresses to physical addresses in RAM.
I will quickly also explain what happens when a virtual memory address cannot be resolved to the physical address required. This is called a page fault, and can either be soft, or hard. A soft fault means that the memory page requested is located somewhere ELSE in RAM (as opposed to the applications physical working set). What Windows does then is moves the page into the physical working set of the process of the current thread's context and be done with it. A hard fault occurs when the memory page requested is not located in RAM at all. In the case of application code, the Windows memory manager will bring it in from the application's executable on disk. In the case of private data, it will bring it in from the page file. In the case of memory mapped files, it will bring it in from the location on disk where the file is mapped from.
Whew. Okay, but you still haven't told us why putting the page file on a RAM disk is bad. Unfortunately, understanding most of the above is required for the explanation. But now that we've got that out of the way, let's get our feet wet with why.
First, lets start with defining one of the major roles of the page file itself: (Paraphrased from Mark Russinovich [http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx])
"One of the roles that the paging file plays is defining the system’s commit limit and how processes contribute to the commit charge."
So what does that mean? Each application contributes to what is called commit charge on the system, and is essentially the amount of virtual memory that can be allocated by all processes as a whole on the system. For example if you had 1GB of RAM and a 2GB paging file, the system commit limit would be 3GB, as this is the total amount of virtual memory allocation that the Windows memory manager can satisfy at any given point. This is where the dreaded "out of memory" error springs from (not so much nowadays). If you were using 2.5GB of that commit limit already and a program tried to use/commit 600MB of memory, Windows will error out because it can't commit to the application that it actually has someplace to store those pages! (i.e. you can't fit 600MB into the remaining 500MB of system commit).
Seeing as we've run out of system commit in our example above, what you would do is either (preferred) buy more RAM, or (preferred for the sake of this thread) increase the size of your page file.
Now what happens if we move the page file to a RAM disk? Lets stick with our crappy system of 1GB of RAM and a 2GB paging file (min/max). Already, we can't put the paging file into a RAM disk! There isn't enough RAM! Okay, so lets make our system a little more modern with a 64-bit OS, we'll give it 4GB of RAM with a 2GB paging file. The total commit limit is 6GB. Let's pretend we have all of that available commit (impossible in the real world, but this makes it simple for the explanation).
The 2GB paging file is now on a RAM disk which is 2GB in size. The RAM disk driver has reserved 2GB of virtual memory. Windows has said "yes, I will reserve this memory for you for some time in the future".
Note that reservation alone does NOT contribute to commit usage, but in the case of the 2GB page file (because the page file is always completely allocated), the RAM disk is definitely using (committed) all of that memory it asked for/reserved. Its commit charge on the system as a whole is 2GB. The amount of system commit available is now only 4GB.
Note also that there are other memory usages that don't contribute to system commit either, but they are beyond the scope of this thread.
Let's say you fire up "HugeMemoryHogApp.exe", which at start up tries to allocate 3GB of virtual memory and touches/uses/commits it all. This succeeds, and brings our system commit down to a mere 1GB. What the hell, I had 6GB system commit available and only ran that one application which committed 3GB of memory, I should still have 3GB! Ah, but you see, the RAM disk has committed 2GB of its own to store the page file... in RAM! So effectively it is like having no page file at all. Without the page file you'd have 4GB total system commit, and that big allocation of 3GB brings system commit down to... guess what, 1GB (we've seen that number before, haven't we)!
The bottom line: You cannot extend something (virtual memory/system commit) by storing that extension (page file) in the thing you want to extend (virtual memory/system commit)!
EDIT: If my explanation is not good enough to convince anyone, I went ahead and asked Windows kernel developer (now on the Windows Azure team), Mark Russinovich for his opinion on the matter... here is the correspondence:

It is so ridiculous he didn't even bother to list any additional repercussions! Hopefully this convinces most people Edited by tompsonn - 1/3/12 at 6:56am