I don't think you want to eliminate the page file from your windows servers. The OS expects and relies on this to be there. We've done exactly what we've always done with physical servers, except we no longer put the page file on its own disk/array/drive letter in a VM. It stays at the C: default.
The other concern which I am not sure about, is how the memory balloon feature would work or not work on a windows system with no page file.
I thought that when the memory balloon expanded to reclaim memory, it basically forced memory contents from the guest OS, into the page file.
I could be wrong, perhaps someone else can confirm or correct this.
If you are never going above 50% usage, then maybe you do not need to worry about the memory ballooning feature, though 50% usage seems a bit low for me.
1 person found this helpful
A Windows server needs virtual memory regardless of being on a physical or virtual system. Windows was designed to use virtual memory, and consequently, the operating system expects virtual memory to be available to it. Windows tends not to function as reliably if you disable virtual memory.
So yes you should have a page file for your virtual machine, regardless of this this you can make sure to allocate enough physical memory to your VM so it does not exhaust physical memory. There are also alot of memory techniques that ESX does to conserve and optimize memory, it's also possible to have the VM you ESX virtual memory (vswp file) if you become overcommitted. See the links below for more info.
The Role of Memory in ESX Server 3 - http://www.vmware.com/pdf/esx3_memory.pdf
Memory resource management in Vmware ESX Server - http://www.vmware.com/pdf/usenix_resource_mgmt.pdf
Understanding memory usage in Windows 2000 - http://www.microsoft.com/technet/prodtechnol/windows2000serv/tips/w2mem.mspx
Memory performance - http://www.vmware.com/community/thread.jspa?threadID=65293
Memory Shares/Limits/Reservations - http://www.vmware.com/community/thread.jspa?threadID=73411
a great collection of memory links, cool
Thanks a lot for the links Bert, I am going over them as we speak. I've found some interesting details already:
Further more, a memory dump isn't available for systems with 2 GB of RAM or more, so the arguement to at least allocate Total Ram + 1 for your paging file doesn't work for these systems.
I will continue to gather information and let you know which memory allocations we've decided, so that others might use them as well. If I find the links to be sufficient I will award you your points
Thats not how memory works in Windows though. Just because it can't address more then 4GB physically, does not mean it cannot address more virtually.
Each -application- believes it has 3GB of addressable space available to it (when /3G is used, otherwise its 2GB in a 4GB system) If enough apps are using more then the 3GB physically, Windows will swap until swap + physical ceiling is hit, then apps start crashing, not working etc. The limit per application is 3GB though, but you can technically have 3 apps each using 3GB of "memory" if you have at least a 6GB page file
You need to evaluate the system before deciding. I'd say start with 1GB min/max and only adjust if you actually see it being used to that level in performance monitoring tools. You could probably get away with a 512MB page file and only 512MB assigned to the VM because the apps it runs only want about 300MB of virtual memory.
K, I know I left A LOT out, but there is a lot to understand.
Thanks Fred, I've taken your advice into consideration, along with esiebert's extensive collection of Memory related links and information.
Since a virtualized server should be treated as a physical server, it's cleary stated in several sources you shouldn't disable the pagefile. Further more, disabling the pagefile would prevent VMWare from succesfully inflating a memory balloon, since the OS can't swap out it's pages (possibly it'll still swap, but to ESX's version of the pagefile. You shouldn't want that to happen however)
I was unable to find any indications on what to do with the size of the pagefile in contrast to server roles or specific applications. For example: Should a pagefile be exceedingly big or small on a SQL server, and how about for a domain controller?
Stated in Fred's link ( http://support.microsoft.com/?kbid=555223 ) :
On the other hand, disk space is usually plentiful, so having a large pagefile (e.g. 1.5 times the installed RAM) does not cause a problem and eliminates the need to fuss over how large to make it.[/i]
This eases the way for us to solve our problem. We were conservative about blindly assigning 1.5 x installed RAM for the size of the pagefile, especially having read the OS can't handle more than 4 GB of memory anyway. Fred cleared the air on that subject and after reading his link we have decided to take the following approach:
On all of our server (except 2) we will set the pagefile locked on the recommended size setting (1.5 times installed RAM). From there on, we will daily monitor pagefile usage for 2 weeks. After these 2 weeks, based on the monitoring reports, we will tune the size of the pagefiles.
Of course, we will gradually implement this solution into our organization, first performing the change and monitoring actions on test servers before going to production. Further more, this will give us a change to see wether monitoring has a significant negative performance impact on our servers (we suspect it will not though)
I stated "except 2", because we have a file server and a SQL server which do not have a pagefile. We will take a different approach for these servers. First, we will monitor memory usage to see if there is a need for a pagefile. Based on those findings, we will determine wether or not to enable the pagefile.
I'd like to thank you all for your help.