Thoughts from the EPS Windows Server Performance Team
It’s October 1st, 2009! That means that it’s time to get started on our Windows 7 and Windows Server 2008 R2 Launch Series. Day One – let’s start at the very beginning, which is usually a very good place to start. Today we’re covering Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing. This post is going to be one of the longest in the series, so strap in – and let’s get started.
Let’s begin with a look at the upgrade paths for Windows 7 and Windows Server 2008 R2. First, the basic upgrade matrix for Windows 7:
Note: There is no supported direct upgrade from Windows XP to Windows 7.
And here is the basic upgrade matrix for Windows Server 2008 R2:
Some things to note about the upgrade paths for both Windows 7 and Windows Server 2008 R2:
OK – let’s briefly go over some of the Registry Enhancements. There were two main areas in which management of the registry in Windows 7 and Windows Server 2008 R2 was enhanced:
Let’s start by taking a look at the locking mechanism. The locking mechanism for registry keys was enhanced in the Windows 7 codebase to minimize performance issues caused by contention for a lock on one or more keys.
The Configuration Manager (CM) stores and maintains configuration information in the registry hives. A Key Control Block (KCB) is a structure that represents a unique registry key (the full path). A KCB table contains hash entries that allow quick reference to KCBs. Multiple KCBs (possibly representing registry keys from different hives) can use the same table entry. Pushlocks are used to lock the KCB table entries.
In previous versions of Windows, the KCB table entry locking mechanism could at times cause deadlock contention and Event ID 333. The reasons for this were:
Let’s move on to WoW64 Redirection and Reflection. Wow64 provides an emulation environment for 32-bit applications to run seamlessly on 64-bit Windows platforms. As a part of this design Wow64 provides separate registry views to 32-bit and 64-bit applications, avoiding conflicts potentially caused by sharing architecture-specific data.
There were two key mechanisms that made this split personality registry design work: Redirection and Reflection.
Redirection: Wow64 does not require applications to have knowledge about the registry layout of a 64-bit OS. It transparently redirects applications to the proper locations depending on the architecture of the application.
Using registry redirection, WoW64 splits the registry at certain points into 32 bit and 64-bit views. For example, keys under HKLM\Software are split. Beneath the keys that are split is a key that represents the redirection point, WoW6432Node. That key is used as the root key for the 32-bit keys. Registry keys that are not split are referred to as “shared” or “merged” keys. The combination of shared and split keys makes up an architecture-specific view, so we have both a 32-bit view and a 64-bit view.
Some common redirection points were:
A redirected key actually consists of two physical keys, which means that the certain parts of the registry are doubled in size. In previous versions of Windows the policy that was used for redirection was “split by default”. This meant that, for example, even if only the key HKLM\Software\MyCompany\MyApp\Parameters contained architecture-specific values, the entire HKLM\Software\MyCompany key might be split, resulting in a much larger than necessary registry footprint.
Reflection: WoW64 used Registry Reflection to copy data between 32-bit and 64-bit copies of split registry keys based on rules to keep COM-specific keys synchronized. In particular, communication between 32-bit and 64-bit COM clients and servers required COM objects and Proxy/Stub DLL registration data to be written in both registry hives. At times, this would cause data inconsistency in the registry because reflection was not atomically performed at the time the key was written.
The following improvements to these features in Windows 7 and Windows Server 2008 R2 reduce the size of the registry, improve registry consistency, and could have an overall impact on performance by reducing memory and CPU usage.
The registry key split policy has been changed to “shared by default”. Now only those keys that contain architecture-specific data are split, greatly reducing the registry footprint. For example, if a 32-bit application needs to update the registry key HKLM\Software\MyCompany\MyApp\Parameters, only that key will be redirected, rather than at the level of one of the parent keys. Reflection has been completely eliminated. It was previously required only for COM components and the need for using reflection has been negated by updating COM to only use shared keys.
Before we wrap up our post for today, let’s go over some changes to Crash Dump Retention and Page Files. One common theme you will see in Windows 7 is an effort to reduce the disk footprint of Windows. The purpose of this effort is not only to preserve disk space on desktops and laptops, but also to accommodate increasingly popular netbooks, which in many cases are available with solid state drives (SSDs) as small as 16 GB. Depending on the amount of memory a machine has, the size of the paging file size and the way that memory dumps are retained can have a significant effect on the disk space used.
Three enhancements in the area of crash dump retention and page file size were introduced in Windows 7 and Windows Server 2008 R2:
Page file size equal to RAM: Prior to Windows 7 the default paging file size was determined differently on different versions of Windows. But in general terms, when the paging file size was configured as “system-managed” its size would typically be calculated as RAM x (some number greater than 1) or RAM + (some number).
In Windows 7 and Server 2008 R2 the default size is equal to the amount of memory installed in the machine. Your gut reaction to this is probably the same as mine was – to get a successful complete memory dump the paging file needs to be a little larger than RAM. How much larger probably goes back to what version of Windows you are running and other factors, but 300 MB is generally considered plenty of padding for the purposes of getting a complete dump.
Not to worry. A default installation of Windows 7 or Server 2008 R2 is configured to generate a kernel memory dump and also with a system-managed paging file size. So a paging file equal to RAM is plenty. If you decide that you want to capture a complete memory dump, simply change the dump option to “Complete memory dump” and restart (be sure to leave the paging file size as system-managed). After the restart the paging file should be RAM + 300 MB. This applies to both client and server SKUs.
New memory dump retention criteria: In the event of a system crash, memory is dumped to the paging file, then copied to the location specified in the Advanced System Properties during the subsequent reboot. After the restart the dump and associated information may be uploaded to Microsoft depending on the Windows Customer Experience Improvement Program options chosen during installation or controlled by the administrator through group policy. Once this process is complete, the dump file will be retained or deleted depending on the following factors:
If the machine is a server SKU and/or joined to a domain, the memory dump is always retained. For client machines not joined to a domain, the dump will be retained as long as the amount of free space on the system drive is greater than 25 GB. If the following registry value is set to “1” then the dump file will be retained regardless of any other factor: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\AlwaysKeepMemoryDump
Configurable mini-dump retention: Unlike complete or kernel memory dumps which are overwritten each time a new system crash occurs, small memory dumps are retained indefinitely (in the folder %WinDir%\Minidump by default). Minidump files are named using the format MiniMMDDYY-nn.dmp, where “MMDDYY” is the date on which the dump was produced and “nn” represents the instance of a minidump produced on that date.
In Windows 7 and Windows Server 2008 R2, the number of minidumps retained can now be controlled by a registry key value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MinidumpsCount. The default value of MinidumpsCount is 50.
Well, that brings us to the end of the first post. Tomorrow, Tim Newton will be going over Memory Management changes and Fault-Tolerant Heap.
- Jim Martin
Look at basic upgrade matrix for Windows Server 2008 R2
the second row path is it for windows server 2003 standard or enterprise??
Jim after reading the post it seems as if we won't have to set the
ctrl+scroll lock +scroll lock registry key. Is that option of pressing those keys still valid in win7 or just selecting the "complete memory dump" from the drop down list is sufficient to generate a complete memory dump? - In case windows 7 /R2 hangs - how is it going to generate the dump on it's own? or are we assuming here that the complete process remains the same?
The behavior is the same as it has always been. A dump still requires the CrashOnCtrlScroll registry key be set and you still have to press CTRL-SCROLL-SCROLL. Windows will not dump on its own during a hang.
@Ravi - good catch on the mistake in the upgrade matrix. I've corrected it.
Thanks guys!!! Askperf rocks!!!
Can you upgrade from one Windows 7 Version to another?
In particular can you upgrade from any version of Windows 7 to Windows 7 Enterprise?
Reason fro question: Accidentally installed 35 corporate laptops with the Windows 7 Pro media and need Enterprise...
Hello, I would like to know whats involved in upgrading from Windows server 2008 to Windows 7, Would I need any new Hardware etc
If you have only a RAID 1 system/Boot volume and a 6 disk RAID 5 data volume on a SQL box, where is the best place for the page file and how much does it matter?
I think I understand the issues of each, but am curious what industry standards indicate.
RAID 1 is the OS partition (BAD), but might be faster during write (no checksum like RAID 5) and the RAID 5 would be MUCH faster during reads (having 6 spindles), perhaps faster during writes (checksum calculated by dedicated processor and writing across 6 spindles) but would be competing with the data under load.
Does the same rule for swap/page files still apply to servers running with ginormous amounts of RAM now, like say 96 GB, 128 GB, etc...should we still let Windows manage the swap file for these or override the default setting and designate smaller swap/page file sizes?
So do the traditional rules (now updated to page file size = RAM for Windows 7/2008 R2 family) of page file size still apply to servers with ginormous amounts of RAM? That is for systems running with 96 GB, 128 GB, etc., should we let the OS manage the page file size or override it to a smaller amount? What about if the system always utilizes less than 50% RAM?