PERFGURU

Technical Blogs on All Kinds of Performance Issues

Guidance on page file size X64 and X32 machines Windows 2003 servers

Guidance on page file size X64 and X32 machines Windows 2003 servers

  • Comments 3
  • Likes

There seems to be a little confusion on the page file sizing on X64 machines and X32 machines as well. Lots of kb articles have been written; am trying to simplify it in this post.

 

On 32 bit machines it is easier to determine the size of the paging file because we generally do not come across machines with huge RAM on it.

There is no hard and a fast rule for a particular size of paging file. It depends on scenario to scenario.

 

Page files have two primary roles

 

A) As a page file to allow virtual memory to provide support along with the Physical RAM on the machine and potentially allow the server to perform better

       

B) For use in generating crash dumps for problem investigation when required.

 

Size required for  scenario A can be argued about, and even whether one is necessary at all, but in general a page file, or page files, of several GB up to or larger than RAM size can be used. And for best performance an additional dedicated page file drive could be used.

 

Size required for scenario B is usually the key factor and relates to the page file on the boot (i.e. Windows) drive, which may have some space constraints of its own.

 

Let us take the scenario B into consideration; as this is where we need the guidance most of the times.

First we need to determine whether we need a complete dump or a kernel only dump. Most of the cases a kernel only dump would suffice.

For most crashes; i.e. blue screens of death a kernel only dump would give sufficient information; but there are times when we would need a complete dump of the system to investigate the problem.

 

32 bit machines:-

===============

1. A kernel only dump would be always <= 2GB due to the 32 bit virtual address space limitation. So a page file of around 2 GB+100 MB should be fine.

2. A kernel only dump with a /3GB switch would always be <= 1GB due to the fact that we are giving the kernel only 1 GB of virtual address space. So a page file of around 1 GB +100 MB should be fine.

3. A Kernel only dump with RAM over 4 GB and PAE switch would always be again <= 2GB due to the virtual address space limitations. So a page file of around 2 GB+100 MB should be fine.

4. A complete dump will require a page file of the size of the Physical RAM +100Mb.

 

64 bit machines:-

================

64 bit machines are where we generally ponder over the size. On a 64 bit machine the Virtual address space is quite large.

Let us have a look at the below table for the address space layouts

 

REGION

IA64

X64

X86

Process Address Space

7152 GB

8192 GB

2 to 3 GB

System PTE Space

128 GB

128 GB

1.2 GB

System Cache

128 GB

128 GB

960 MB

Paged Pool

128 GB

128 GB

470 to 650 MB

Non Paged Pool

128 GB

128 GB

256 MB

 

Looking at the above the kernel on X64 Machines could go potentially to the size of the Physical RAM. Most of the machines we have seen are with 64 GB RAM on it .i.e. the high end machines. For ex  a bad driver  leaking Non paged Pool memory on a machine with 64 GB RAM could potentially take up the whole of the Physical RAM as we can see from the table that the mapping capability of the NPP is 128 GB on X64 machines. From the past experience we see the below

 

1. A kernel only dump on midrange machines would grow up 4 GB. So a paging file of the size of around 4GB +100 Mb is fine

 

2. A kernel only dump on a high end machine would grow up to 16 GB. So a paging file of the size around 16 GB +100 Mb is fine.

 

3. A complete dump requires the size of the Physical RAM +100 Mb.

For getting a near exact figure of the page file we would recommend you to monitor the Memory usage on the system using the perfmon ; which will give you a very good idea .

 

4. Also please note dumping out boxes with huge amounts of RAM would cause significant down time before it can reboot and come back. A 16 GB dump may take around 40 minutes approximately.  

 

Following are the important considerations for a page file for the dump creation

 

1. For a dump creation it is MANDATORY for the page file to be on the Windows Drive. (C:)

2. You can re direct the dump to another drive to save space on your system drive. It is not MANDATORY that the dump should be saved on the C drive.

3. For a complete dump option in the GUI you will have to edit the following registry key

Change the value from 0x2 to 0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Value Name: CrashDumpEnabled

Data Type:  REG_DWORD

Value: 1

4. On Windows 2008 and Vista the page file used for creating dumps has changed .

 

 

 

 

Comments
  • PingBack from http://blog.rustice.com.br/2008/09/24/consideracoes-sobre-o-tamanho-do-pagefile-no-windows-2003-de-32-e-64bits/

  • Hi Sri,

    PF Usage in Windows XP and Windows Server 2003 is actually the system commit total. This number represents potential page file usage, not actual page file usage. It is how much page file space would be used if all the private committed virtual memory in the system had to be paged out all at once.

    System Perfmonace depends on many factors eg Memory, Processor ,Disk and load on server etc. I would say, performance monitor will be your friend here to check the system performance and bottle neck (If any).

    To check physical memory usage you can use the following counters in performance monitor.

    Memory\ Available Bytes   -> This counter could help you in find the available memory .If this value is less constantly then you need to update RAM.

    Below two counters are for virtual memory usage.

    Memory\ Pool NonPaged Bytes

    Memory\ Pool Paged Bytes

    Hope this will help you to understand how to proceed :)

    Pawan

  • Hola Realmente el post anterior era para poder poner este. En una m&#225;quina virtual, &#191;c&#243;mo

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment