Thursday, June 28, 2007

/3GB /USERVA=3030 parameters on the boot.ini




Let's understand why we need to perform some tuning in Exchange servers. Microsoft recommends editing to boot.ini file on Exchange servers if they have more than 1GB memory installed. Why we need to do this, to optimize the virtual memory usage of the Information Store service. Here is official Microsoft explanation under typical circumstances and for each process, 2 GB of virtual address space is allotted for the user-mode process, and another 2 GB of virtual address space is allotted to the operating system. When you use the /3GB switch in Windows Server 2003, 3 GB of virtual address space is allotted for the user-mode process, and only 1 GB of virtual address space is allotted to the operating system. This reallocation of the extra 1 GB of address space helps to resolve the problem of memory fragmentation in the Store.exe virtual address space. With the larger address space allocated to Store.exe, memory can be more easily joined before all large memory blocks are used.


[Boot loader]

redirect=usebiossettings

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /redirect /3GB /USERVA=3030


So all you need to do is adding this extra switch into boot.ini and saving it. (make sure the boot.ini is NOT read only)

/3GB /USERVA=3030

Note Make sure that the Store.exe process does not run out of virtual address space. If this behavior occurs, memory allocations fail (even if there is plenty of physical RAM remaining), and you must restart the Microsoft Exchange information store service.

For example, a server with 2 GB of physical RAM that does not have the /3GB switch in the Boot.ini file will run out of memory when the Store.exe virtual address space reaches 2 GB. Windows Task Manager shows that only about 1.5 GB is actually being used in this scenario, but the server will still be out of memory.

The /USERVA switch is new to Windows Server 2003 and provides better granularity for splitting memory allocations between user mode and kernel mode. This behavior lets you scale the server to a greater number of users without the risk of exhausting system resources. By using /USERVA=3030, an additional 42 megabytes (MB) of memory is allocated to the kernel for page table entries (PTEs). However, this value may need more tuning. You can monitor the PTE consumption by using Performance Monitor. The object to monitor is Free System Page Table Entries. If values that are less than 7000 are observed, the value of 3030 must be reduced because the system is unstable. If the value is less that 20,000, reduce the value in 64-MB steps until values that are greater than 20,000 are

the server to a greater number of users without the risk of exhausting system resources. By using /USERVA=3030, an additional 42 megabytes (MB) of memory is allocated to the kernel for page table entries (PTEs). However, this value may need more tuning. You can monitor the PTE consumption by using Performance Monitor. The object to monitor is Free System Page Table Entries. If values that are less than 7000 are observed, the value of 3030 must be reduced because the system is unstable. If the value is less that 20,000, reduce the value in 64-MB steps until values that are greater than 20,000 are observed.

Note Microsoft Product Support Services strongly recommends using a range of memory that is within the range of 2800 to 3030 for the /USERVA switch. This range is wide enough to provide a large enough pool of system PTEs for all currently observed issues. Typically, a setting of /userva=2800 provides close to the maximum available number of system PTEs that are possible. Currently, Microsoft Product Support Services has not seen an Exchange Server computer that requires values that are less than 2900.

You may also monitor the virtual address consumption by using Performance Monitor. Add the Virtual Bytes counter for the Store.exe process to make sure of an accurate reading of the virtual space. The Store.exe process is the only Exchange 2003 process that you must monitor. Other Exchange 2003 processes will not grow sufficiently large to cause any problems.

Because Exchange Server uses the /3GB switch as it scales up, the Exchange Server computer cannot efficiently use more than 4 GB of RAM. Exchange Server does not support instancing, Physical Address Extension (PAE), or Address Windowing Extensions (AWE). Therefore, 4 GB of RAM is the maximum amount of memory that an Exchange Server computer can efficiently use

http://support.microsoft.com/kb/823440

Best

Oz ozugurlu

2 comments:

Anonymous said...

Does this still apply to Exchange 2007 on WIndows 2003 x64? It would be nice if Microsoft would add some info about e2k7 to the existing e2k3 article.

Oz Ozugurlu said...

Here you go, the process seems to be done automatically in 64 Bit Platform

On 64-bit versions of Windows Server 2003, the system automatically expands the virtual address space available to 32-bit user-mode programs linked with the /LARGEADDRESSAWARE option as needed without the /3GB boot parameter. On Windows Server 2003 RTM (without Service Pack 1), these 32-bit programs can access up to 3 GB of virtual address space. On Windows Server 2003 with Service Pack 1, they can access up to 4 GB of virtual address space. Native 64-bit user-mode programs can access up to 8 TB of virtual address space.
Booting with the /3GB parameter decreases the amount of kernel virtual address space on the system. In order to fit all of the kernel resources within the remaining 1 GB of virtual memory, NT-based Windows operating systems prior to Windows Vista, Windows restricts physical memory to frames below the 16 GB physical boundary and on Windows Vista, it restricts physical memory to frames below the 64 GB boundary. Because allocation of memory resources in Windows Vista is dynamic and, therefore, more adaptable and efficient, the system can devote more memory space to addressing, thereby accommodating more physical memory.
The following table lists the physical memory limits of 32-bit Windows operating systems that support the use of more than 4 GB of physical memory with and without the /3GB boot parameter.http://msdn2.microsoft.com/en-us/library/ms791558.aspx

best
oz