This is the 2nd part of a series of posts I’ll be describing several settings and parameters that can be tuned to optimize your server performance. I hope you’ll find them useful and help you improve your servers performance.
- Performance Tuning your Windows Server (Part 1)
- Performance Tuning your Windows Server (Part 3)
- Performance Tuning your Windows Server (Part 4)
Note: As with all changes, you should implement the following suggestions one at a time and verify that there was a performance improvement. If system performance decreases after making a change, you should reverse the change.
When Windows is first installed, many services are enabled that might not be necessary for a particular server. Each service requires system resources and as a result is best to disable unnecessary services to improve performance. All services that are not required to be running on the server should be stopped and disabled. This will prevent the service from automatically starting at system boot time.
Note: Unless you are completely certain of the purpose of a given service it is recommended to research it further before choosing to disable it.
For example, the Print Spooler service is enabled by default but is not usually required if the server is not functioning as a print server or does not have local printing requirements.
But don’t disable the Spooler on your Domain Controllers. Printers which are advertised in Active Directory are monitored periodically by the DCs which have the spooler service enabled and running that they actually exist on the associated print server(s). If and when printers are found which do not exist on a print server, the spooler service will remove the associated object from AD. Thus, if all spooler services (on DCs) are disabled, print queues advertised in AD will need to be manually managed. See http://support.microsoft.com/kb/246269/ for more details.
The table below lists a few services on a standard Windows Server 2003 installation that should be reviewed for their requirement on your systems.
|Service||Default startup type||Recommended setting|
|Distributed file system||Automatic||Disabled|
|Error Reporting Service||Automatic||Disabled|
|Help and Support||Automatic||Disabled|
The NTLDR (NT Loader) allows the user to choose which operating system to boot from at the menu; for NT and NT-based operating systems, it also allows the user to pass preconfigured options to the kernel. The menu options are stored in the boot.ini file. There are several switch options for the boot.ini file. I’ll describe 3 of them that have to do with memory management.
By default, the 32-bit (x86) editions of Windows can address a total of 4 GB of virtual address space. This is a constraint of the 32-bit (x86) architecture. Normally, 2 GB of this is reserved for the operating system kernel requirements (privileged-mode) and the other 2 GB is reserved for application (user-mode) requirements. Under normal circumstances, this creates a 2 GB per-process address limitation.
Windows provides a /3GB parameter to be added to the BOOT.INI file that reallocates 3 GB of memory to be available for user-mode applications and reduces the amount of memory for the system kernel to 1 GB. Some applications, written to do so, can derive performance benefits from having large amounts of addressable memory available to individual user-mode processes. In such instances, having as much free space for user-mode processes is desirable.
You normally use this switch only when a specific application recommends its use, meaning the applications have been compiled to use more than 2 GB per process, such as Microsoft Exchange and Microsoft SQL Server.
The Physical Address Extension (PAE) is a 36-bit memory addressing mode that allows 32-bit (x86) systems to address memory above 4 GB.
Windows uses 4 KB pages with PAE to map up to 64 GB of physical memory into a 32-bit (4 GB) virtual address space. The kernel creates a “map” in the privileged mode addressable memory space to manage the physical memory above 4 GB.
This allows the operating system to use physical memory above 4 GB. As the 64-bit (x64) editions of Windows are not bound by this same memory architecture constraint, the PAE switch is not used in these versions of the Windows Server.
Even with PAE enabled, the underlying architecture of the system is still based on 32-bit linear addresses. This effectively retains the usual 2 GB of application space per user-mode process and the 2 GB of kernel mode space because only 4 GB of addresses are available. However, multiple processes can immediately benefit from the increased amount of addressable memory because they are less likely to encounter physical memory restrictions and begin paging.
The /userva=#### switch is designed to allow for more precise tuning of User-mode address space for programs that require more than 2 GB of User-mode space but do not require all the space that is provided by the /3GB tuning switch alone. Using the /3GB switch reduces the memory available in the Nonpaged Pool, Paged Pool & System Page Table Entries (PTEs).
If the memory reduction in the pools is too great in a specific server installation, the server or the applications may generate an error or appear to stop responding.
Using the /userva switch you can add a small amount of the additional 1 GB back to the operating system by decreasing the amount of User-mode space that is typically allocated by the /3GB switch. This additional Kernel-mode address space is held in reserve and is used as additional address space for PTEs if the system runs out of free PTE space. This address space is not allocated to PTEs until the system runs low on PTE space.
Use /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB, with the difference (3,072 less ####) being returned to Kernel mode. Note that #### is expressed in megabytes (MB).