It’s February 1, 2008. Only twenty-six more days until Windows Server 2008 is released to the world. With that in mind, we have twenty-six posts lined up between now and February 27 covering areas of Windows Server 2008 that contain both general information as well as specific posts that are relevant to what we support here on the Performance team. So without further ado, let’s dive right in, beginning with the upgrade paths available for Windows Server 2008 shown in the table below:
|If you are currently running:||You can upgrade to:|
|Windows Server 2003 Standard Edition (R2, Service Pack 1 or Service Pack 2)||Full Installation of Windows Server 2008 Standard Edition |
Full Installation of Windows Server 2008 Enterprise Edition
|Windows Server 2003 Enterprise Edition (R2, Service Pack 1 or Service Pack 2)||Full Installation of Windows Server 2008 Enterprise Edition|
|Windows Server 2003 Datacenter Edition (R2, Service Pack 1 or Service Pack 2)||Full Installation of Windows Server 2008 Datacenter Edition|
There are a couple of important things to remember here. First, with the exception of Windows Server 2008 for Itanium, the table above applies to both x86 and x64 versions. However, cross-platform upgrades (x86 to x64 or vice-versa) are not supported. It is also not possible to upgrade from a previous version of Windows to Windows Server 2008 Server Core Edition.
With respect to resource limits, there are also some changes to be aware of. Many values that are dynamically configured for 32-bit versions of Windows Server 2008 are set to their maximum values in 64-bit versions since the virtual address range is much larger. The notable exception to this rule is the NonPaged pool which is dependent on the amount of physical RAM installed. The table below outlines the resource limits:
|Memory Type||32-bit Windows||64-bit Windows|
|User mode virtual address space for 32-bit processes||2 GB (up to 3 GB with 4GT RAM tuning)||2 GB (4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE)|
|User mode virtual address space for 64-bit processes||N/A||8 TB on x64, 7 TB on IA-64 (2 GB without IMAGE_FILE_LARGE_ADDRESS_AWARE)|
|Kernel mode virtual address space||2 GB (1 GB to 2 GB with 4GT RAM tuning)||8 TB|
|Paged Pool||Dynamic – limited by kernel mode virtual address space and physical memory||128 GB|
|NonPaged pool||Dynamic – limited by kernel mode virtual address space and physical memory||75% of RAM up to a maximum of 128GB|
|System cache virtual address space||Dynamic – limited by kernel mode virtual address space and physical memory||1 TB|
|Desktop Heap||3 MB for interactive desktop by default, however this is a tunable value||20 MB for interactive desktop by default, again this value is tunable|
|System Page Table Entries||Dynamic – limited by kernel mode virtual address space and physical memory||Dynamic – limited by kernel mode virtual address space and physical memory|
|Maximum registry hive size||2 GB*||2 GB*|
* – the maximum registry hive size excludes the System hive. The System hive size is determined as follows:
- x86: 400 MB or 50% of physical memory, whichever is smaller
- x64: 1.5 GB or 50% of physical memory, whichever is smaller
- IA-64: 32 MB
Finally, let’s take a look at some of the key Memory Management registry value limits. In the table below, several values are listed as Not Used. These values are still present in the registry with default values to provide backward compatibility for applications that may rely on these values (the Default (NP) column refers to values that are inherent to the operating system, but are not explicitly defined in the registry. To make use of these values, you would need to add them to the registry manually.
|Value||Location in HKEY_LOCAL_MACHINE||Default (NP)||Default||Min||Max|
|PoolUsageMaximum||System\CurrentControlSet\Control\Session Manager\Memory Management||80||5||100|
|PagedPoolSize||System\CurrentControlSet\Control\Session Manager\Memory Management||Not Used||Not Used||Not Used|
|LargeSystemCache||System\CurrentControlSet\Control\Session Manager\Memory Management||Not Used||Not Used||Not Used|
|SystemPages||System\CurrentControlSet\Control\Session Manager\Memory Management||Not Used||Not Used||Not Used|
|SessionViewSize||System\CurrentControlSet\Control\Session Manager\Memory Management||Not Used||Not Used||Not Used|
|SessionPoolSize||System\CurrentControlSet\Control\Session Manager\Memory Management||Not Used||Not Used||Not Used|
|GDIProcessHandleQuota *||Software\Microsoft\Windows NT\CurrentVersion\Windows||10000||10000||256|
|UserProcessHandleQuota *||Software\Microsoft\Windows NT\CurrentVersion\Windows||10000||10000||0|
|RegistryLazyFlushInterval||System\CurrentControlSet\Control\Session Manager\Memory Management||5||0|
* – the maximum values are too high for practical use, however there is no specific per-process limit.
In January 2007, we wrote a post regarding Processes consuming large amounts of Virtual Memory when the system started. In that post we talked a little bit about memory fragmentation, which occurs when there is enough available total free memory for a process, however there is insufficient contiguous free memory. Over time, due to the varying sizes and lifetimes of the memory allocations, memory fragmentation occurs. 32-bit versions of Windows Server 2008 and Windows Vista SP1 include support for five new memory management registry values used to specify maximum allowed usage values for kernel resources. The table below outlines the new values. By default, these values are not present, and the resources are dynamically managed. The valid range for these values is 0, which indicates no enforced limit up to the available kernel address space, which is 2 GB (2048 MB) by default.
|NonPaged Pool||NonPagedPoolLimit||Specifies the maximum amount of system virtual address space that can be used by nonpaged pool|
|Paged Pool||PagedPoolLimit||Specifies the maximum amount of system virtual address space that can be used by paged pool|
|System Cache||SystemCacheLimit||Specifies the maximum amount of system virtual address space that can be used by system cache|
|System PTE’s||SystemPtesLimit||Specifies the maximum amount of system virtual address space that can be used by system page table entries (PTE’s)|
|Overall Session Space||SessionSpaceLimit||Specifies the maximum amount of system virtual address space that can be used by session space allocations. The session space is divided into four areas: session image space, session structure, session view space and session paged pool. See our post on Sessions, Desktops and Windows Stations for more details|
These new memory management values were provided to allow resource limits to be set in the event that the resources became depleted due to severe fragmentation. These values should not be set without careful analysis and a complete understanding of the ramifications. It is highly unlikely that there will be a need to set these values without assistance from Microsoft Product Support.
That brings us to the end of this post. Tomorrow, we will cover Startup Processes and Delayed Automatic Start. Until next time …
|Share this post :|
2/4/2008: Something I should have mentioned right at the start – before doing any in-place upgrades, please test your applications etc thoroughly in an isolated environment, and contact the application vendors to find out if their applications will be supported in an in-place upgrade scenario. Case in point – you cannot perform an in-place upgrade of an Exchange Server 2007 machine from Windows Server 2003 to Windows Server 2008. The Exchange Team tried – they wrote a post about it called Mission Impossible: In-Place Upgrading Microsoft Exchange Server 2007 from Windows Server 2003 to Windows Server 2008.