VMware Cloud Community
nev
Contributor
Contributor

Setting Page File on VM's

Hi,

Been trawling thru the discussions but can't find anything relating to this.

Should VM's page files be set as per the recognised MS standard (well recognised in the firms I've worked at) of x2.5 RAM fixed?

E.g. if I have a VM with 384mb ram, do I set the page file to be x2.5 that amount on a separate partition (D:) drive?

Thanks.

0 Kudos
6 Replies
oreeh
Immortal
Immortal

Should VM's page files be set as per the recognised MS standard

Yes - Windows requires a page file for proper operation and to be safe use the standards.

If you use a dedicated swap partition depends on your needs / your corporates best practices.

0 Kudos
Ken_Cline
Champion
Champion

A rather lengthy thread on this topic: http://www.vmware.com/community/message.jspa?messageID=614413#614413

Ken Cline VMware vExpert 2009 VMware Communities User Moderator Blogging at: http://KensVirtualReality.wordpress.com/
0 Kudos
nev
Contributor
Contributor

Thanks for that, strange how depending on which MS material you read the recognised page file standard goes from x1.5, x2, x2.5 physical RAM installed...

Looks like keeping a page file x1.5 RAM allocated to the vm is the way forward according to that thread.

MS always advised to keep the page file on another drive for performance reasons, perhpas that isnt' so important in the virutal world after reading that thread?

Additionally, they always used to advise to keep the page file fixed to avoid fragmentation, I guess this is still true?

If so, if you added more RAM to your VM you would then have to go and change the page file size to accomodate this. Where as if you had the VM using system managed size you wouldn't have to bother.

Too many options! How have you guys set yours? Fixed or system allocated and on which drive? We always use a (D:) Swap partition on our physical servers

0 Kudos
oreeh
Immortal
Immortal

perhpas that isnt' so important in the virutal world after reading that thread?

this really depends on your VMs, a nearly unused VM will behave different than a heavy loaded VM

Additionally, they always used to advise to keep the page file fixed to avoid fragmentation, I guess this is still true?

yes this still is true

I normally use a fixed page file on the C: partition with the double mem size

(I don't change the memsize of VMs often)

0 Kudos
m_d_sella
Enthusiast
Enthusiast

I may stand corrected, but I believe that for Windows to process a dump of physical memory (virtualized in this case), the page file must reside on the system partition and be of at least "Physical Mem. Size + 1" (up to a maximum of 2060 MB). We have never to my knowledge needed to retrieve such a file, nor would it be easy to send/process a file of this size in the event of a memory dump. It is a unlikely scenario, but one to consider.

Also, we use a fixed size and I have read in several documents that it is recommended to set the minimum and maximum size to the same value. When these values are left as a range, Windows is forced to dynamically resize the page file when more virtual memory space is needed, and this sizing algorithm can produce unwanted overhead. The drawback to this configuration is that you will sacrifice more disk space up front.

Just a few quick tips that I have run accross during my performacne tuning. Hopefully they help.

0 Kudos
continuum
Immortal
Immortal

Don't know if this makes sense on ESX ...

On VMserver or Workstation I use a pagefile with the maximum size that Windows can use - 4096MB.

I put this into a separate SPARSE virtual disk.

This way Windows always thinks it has the luxury of a large pagefile - while at the same time the virtual disk stays very small in size as VMs actually do not use pagefiles as often as physical machines ...

As Windows likes to have a pagefile on %systemdrive% I assign a little 50MB pagefile on the systemdrive.


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0 Kudos