• Correct Memory Sizing for Child Partitions
  • Correct Memory Sizing for Root Partition
  • Storage I/O Performance
  • Types of Virtual Hard Disk Files
  • Block Size Considerations
  • Sector Size Implications
  • Support for Native 4 K Disks
  • Advanced Storage Features
  • Offloaded Data Transfer Integration
  • Performance Tuning Guidelines for Windows Server 2012 April 12, 2013 Abstract




    Download 0.61 Mb.
    bet23/26
    Sana21.03.2017
    Hajmi0.61 Mb.
    1   ...   18   19   20   21   22   23   24   25   26

    Memory Performance


    The hypervisor virtualizes the guest physical memory to isolate virtual machines from each other and to provide a contiguous, zero-based memory space for each guest operating system. In general, memory virtualization can increase the CPU cost of accessing memory. On non-SLAT-based hardware, frequent modification of the virtual address space in the guest operating system can significantly increase the cost.

    Enlightened Guests


    Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008 include kernel enlightenments and optimizations to the memory manager to reduce the CPU overhead from memory virtualization in Hyper-V. Workloads that have a large working set in memory can benefit from using Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008 as a guest. These enlightenments reduce the CPU cost of context switching between processes and accessing memory. Additionally, they improve the multiprocessor scalability of Windows Server guests.

    Correct Memory Sizing for Child Partitions


    You should size virtual machine memory as you typically do for server applications on a physical computer. You must size it to reasonably handle the expected load at ordinary and peak times because insufficient memory can significantly increase response times and CPU or I/O usage.

    You can enable Dynamic Memory to allow Windows to size virtual machine memory dynamically. The recommended initial memory size for Windows Server 2012 guests is at least 512 MB. With Dynamic Memory, if applications in the virtual machine experience launching problems, you can increase the page file size for the virtual machine.

    To increase the virtual machine page file size, navigate to Control Panel > System > Advanced System Settings > Advanced. From this tab, navigate to Performance Settings > Advanced > Virtual memory. For the Custom size selection, configure the Initial Size to the virtual machine’s Memory Demand when virtual machine reaches its steady state, and set the Maximum Size to three times the Initial Size.

    For more information, see the Hyper-V Dynamic Memory Configuration Guide.



    When running Windows in the child partition, you can use the following performance counters within a child partition to identify whether the child partition is experiencing memory pressure and is likely to perform better with a higher virtual machine memory size.

    Performance counter

    Suggested threshold value

    Memory – Standby Cache Reserve Bytes

    Sum of Standby Cache Reserve Bytes and Free and Zero Page List Bytes should be 200 MB or more on systems with 1 GB, and 300 MB or more on systems with 2 GB or more of visible RAM.

    Memory – Free & Zero Page List Bytes

    Sum of Standby Cache Reserve Bytes and Free and Zero Page List Bytes should be 200 MB or more on systems with 1 GB, and 300 MB or more on systems with 2 GB or more of visible RAM.

    Memory – Pages Input/Sec

    Average over a 1-hour period is less than 10.



    Correct Memory Sizing for Root Partition


    The root partition must have sufficient memory to provide services such as I/O virtualization, virtual machine snapshot, and management to support the child partitions. Hyper-V calculates an amount of memory known as the root reserve, which is guaranteed to be available to the root partition and never assigned to virtual machines. It is calculated automatically, based on the host’s physical memory and system architecture. This logic applies for supported scenarios with no applications running in the root partition.

    Storage I/O Performance


    This section describes the different options and considerations for tuning storage I/O performance in a virtual machine. The storage I/O path extends from the guest storage stack, through the host virtualization layer, to the host storage stack, and then to the physical disk. Following are explanations about how optimizations are possible at each of these stages.

    Virtual Controllers


    Hyper-V offers three types of virtual controllers : IDE, SCSI, and Virtual host bus adapters (HBAs).
    IDE

    IDE controllers expose IDE disks to the virtual machine. The IDE controller is emulated, and it is the only controller that is available when the Integration Services are not installed on the guest. Disk I/O that is performed by using the IDE filter driver that is provided with the Integration Services is significantly better than the disk I/O performance that is provided with the emulated IDE controller. We recommend that IDE disks be used only for the operating system disks because they have performance limitations due to the maximum I/O size that can be issued to these devices.
    SCSI

    SCSI controllers expose SCSI disks to the virtual machine, and each virtual SCSI controller can support up to 64 devices. For optimal performance, we recommend that you attach multiple disks to a single virtual SCSI controller and create additional controllers only as they are required to scale the number of disks connected to the virtual machine.
    Virtual HBAs

    Virtual HBAs can be configured to allow direct access for virtual machines to Fibre Channel and Fibre Channel over Ethernet (FCoE) LUNs. Virtual Fibre Channel disks bypass the NTFS file system in the root partition, which reduces the CPU usage of storage I/O.

    Large data drives and drives that are shared between multiple virtual machines (for guest clustering scenarios) are prime candidates for virtual Fibre Channel disks.

    Virtual Fibre Channel disks require one or more Fibre Channel host bus adapters (HBAs) to be installed on the host. Each host HBA is required to use an HBA driver that supports the Windows Server 2012 Virtual Fibre Channel/NPIV capabilities. The SAN fabric should support NPIV, and the HBA port(s) that are used for the virtual Fibre Channel should be set up in a Fibre Channel topology that supports NPIV.

    To maximize throughput on hosts that are installed with more than one HBA, we recommend that you configure multiple virtual HBAs inside the Hyper-V virtual machine (up to four HBAs can be configured for each virtual machine). Hyper-V will automatically make a best effort to balance virtual HBAs to host HBAs that access the same virtual SAN.


    Virtual Disks


    Disks can be exposed to the virtual machines through the virtual controllers. These disks could be virtual hard disks that are file abstractions of a disk or a pass-through disk on the host.

    Virtual Hard Disks


    There are two virtual hard disk formats, VHD and VHDX. Each of these formats supports three types of virtual hard disk files.
    VHD Format

    The VHD format was the only virtual hard disk format that was supported by Hyper-V in past releases. In Windows Server 2012, the VHD format has been modified to allow better alignment, which results in significantly better performance on new large sector disks.

    Any new VHD that is created on a Windows Server 2012 operating system has the optimal 4 KB alignment. This aligned format is completely compatible with previous Windows Server operating systems. However, the alignment property will be broken for new allocations from parsers that are not 4 KB alignment-aware (such as a VHD parser from a previous version of Windows Server or a non-Microsoft parser).

    Any VHD that is moved from a previous release does not automatically get converted to this new improved VHD format.

    You can check the alignment property for all the VHDs on the system, and it should be converted to the optimal 4 KB alignment. You create a new VHD with the data from the original VHD by using the Create-from-Source option.


    VHDX Format

    VHDX is a new virtual hard disk format introduced in Windows Server 2012, which allows you to create resilient high-performance virtual disks up to 64 terabytes. Benefits of this format include:

    • Support for virtual hard disk storage capacity of up to 64 terabytes.

    • Protection against data corruption during power failures by logging updates to the VHDX metadata structures.

    • Ability to store custom metadata about a file, which a user might want to record, such as operating system version or patches applied.

    The VHDX format also provides the following performance benefits (each of these is detailed later in this guide):

    • Improved alignment of the virtual hard disk format to work well on large sector disks.

    • Larger block sizes for dynamic and differential disks, which allows these disks to attune to the needs of the workload.

    • 4 KB logical sector virtual disk that allows for increased performance when used by applications and workloads that are designed for 4 KB sectors.

    • Efficiency in representing data, which results in smaller file size and allows the underlying physical storage device to reclaim unused space. (Trim requires pass-through or SCSI disks and trim-compatible hardware.)

    When you upgrade to Windows Server 2012, we recommend that you convert all VHD files to the VHDX format due to these benefits. The only scenario where it would make sense to keep the files in the VHD format is when a virtual machine has the potential to be moved to a previous release of the Windows Server operating system that supports Hyper-V.

    Types of Virtual Hard Disk Files


    There are three types of VHD files. Following are the performance characteristics and trade-offs between the three VHD types.
    Fixed type

    Space for the VHD is first allocated when the VHD file is created. This type of VHD file is less apt to fragment, which reduces the I/O throughput when a single I/O is split into multiple I/Os. It has the lowest CPU overhead of the three VHD file types because Reads and Writes do not need to look up the mapping of the block.
    Dynamic type

    Space for the VHD is allocated on demand. The blocks in the disk start as zeroed blocks, but they are not backed by any actual space in the file. Reads from such blocks return a block of zeros. When a block is first written to, the virtualization stack must allocate space within the VHD file for the block, and then update the metadata. This increases the number of necessary disk I/Os for the Write and increases CPU usage. Reads and Writes to existing blocks incur disk access and CPU overhead when looking up the blocks’ mapping in the metadata.
    Differencing type

    The VHD points to a parent VHD file. Any Writes to blocks not written to result in space being allocated in the VHD file, as with a dynamically expanding VHD. Reads are serviced from the VHD file if the block has been written to. Otherwise, they are serviced from the parent VHD file. In both cases, the metadata is read to determine the mapping of the block. Reads and Writes to this VHD can consume more CPU and result in more I/Os than a fixed VHD file.

    The following recommendations should be taken into consideration with regards to selecting a VHD file type:



    • When using the VHD format, we recommend that you use the fixed type because it has better resiliency and performance characteristics compared to the other VHD file types.

    • When using the VHDX format, we recommend that you use the dynamic type because it offers resiliency guarantees in addition to space savings that are associated with allocating space only when there is a need to do so.

    • The fixed type is also recommended, irrespective of the format, when the storage on the hosting volume is not actively monitored to ensure that sufficient disk space is present when expanding the VHD file at run time.

    • Snapshots of a virtual machine create a differencing VHD to store Writes to the disks. Having only a few snapshots can elevate the CPU usage of storage I/Os, but might not noticeably affect performance except in highly I/O-intensive server workloads. However, having a large chain of snapshots can noticeably affect performance because reading from the VHD can require checking for the requested blocks in many differencing VHDs. Keeping snapshot chains short is important for maintaining good disk I/O performance.

    Block Size Considerations


    Block size can significantly impact performance. It is optimal to match the block size to the allocation patterns of the workload that is using the disk. If an application is allocating in chunks of, for example, 16 MB, it would be optimal to have a virtual hard disk block size of 16 MB. A block size of >2 MB is possible only on virtual hard disks with the VHDX format. Having a larger block size than the allocation pattern for a random I/O workload will significantly increase the space usage on the host.

    Sector Size Implications


    Most of the software industry has depended on disk sectors of 512 bytes, but the standard is moving to 4 KB disk sectors. To reduce compatibility issues that might arise from a change in sector size, hard drive vendors are introducing a transitional size referred to as 512 emulation drives (512e).

    These emulation drives offer some of the advantages that are offered by 4 KB disk sector native drives, such as improved format efficiency and an improved scheme for error correction codes (ECC). They come with fewer compatibility issues that would occur by exposing a 4 KB sector size at the disk interface.


    Support for 512e Disks


    A 512e disk can perform a Write only in terms of a physical sector—that is, it cannot directly write a 512byte sector that is issued to it. The internal process in the disk that makes these Writes possible follows these steps:

    • The disk reads the 4 KB physical sector to its internal cache, which contains the 512-byte logical sector referred to in the Write.

    • Data in the 4 KB buffer is modified to include the updated 512-byte sector.

    • The disk performs a Write of the updated 4 KB buffer back to its physical sector on the disk.

    This process is called “Read-Modify-Write” or RMW. The overall performance impact of the RMW process depends on the workloads. The RMW process causes performance degradation in virtual hard disks for the following reasons:

    • Dynamic and differencing virtual hard disks have a 512-byte sector bitmap in front of their data payload. In addition, footer, header, and parent locators align to a 512-byte sector. It is common for the virtual hard disk driver to issue 512-byte Writes to update these structures, resulting in the RMW process described earlier.

    • Applications commonly issue Reads and Writes in multiples of 4 KB sizes (the default cluster size of NTFS). Because there is a 512-byte sector bitmap in front of the data payload block of dynamic and differencing virtual hard disks, the 4 KB blocks are not aligned to the physical 4 KB boundary. The following figure shows a VHD 4 KB block (highlighted) that is not aligned with physical 4 KB boundary.



    Figure 15: VHD 4 KB block

    Each 4 KB Write that is issued by the current parser to update the payload data results in two Reads for two blocks on the disk, which are then updated and subsequently written back to the two disk blocks. HyperV in Windows Server2012 mitigates some of the performance effects on 512e disks on the VHD stack by preparing the previously mentioned structures for alignment to 4 KB boundaries in the VHD format. This avoids the RMW effect when accessing the data within the virtual hard disk file and when updating the virtual hard disk metadata structures.

    As mentioned earlier, VHDs that are copied from previous versions of Windows Server will not automatically be aligned to 4 KB. You can manually convert them to optimally align by using the Copy from Source disk option that is available in the VHD interfaces.

    By default, VHDs are exposed with a physical sector size of 512 bytes. This is done to ensure that physical sector size dependent applications are not impacted when the application and VHDs are moved from a previous version of Windows Server to Windows Server 2012.

    After you confirm that all VHDs on a host are not impacted by changing the physical sector size to 4 KB, you can set the following registry key to modify all the physical sector sizes of all the VHDs on that host to 4 KB. This helps systems and applications that are 4 KB-aware to issue 4 KB sized I/Os to the VHDs.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vhdmp\Parameters\ Vhd1PhysicalSectorSize4KB = (REG_DWORD)

    A non-zero value will change all VHDs to report 4k physical sector size.

    By default, disks with the VHDX format are created with the 4 KB physical sector size to optimize their performance profile regular disks and large sector disks.

    Support for Native 4 K Disks


    HyperV in Windows Server 2012 makes it possible to store virtual hard disks. This is done by implementing a software RMW algorithm in the virtual storage stack layer that converts 512-byte access and update requests to corresponding 4 KB accesses and updates.

    Because VHD file can only expose themselves as 512-byte logical sector size disks, it is very likely that there will be applications that issue 512-byteI/O requests. In these cases, the RMW layer will satisfy these requests and cause performance degradation. This is also true for a disk that is formatted with VHDX that has a logical sector size of 512 bytes.

    It is possible to configure a VHDX file to be exposed as a 4 KB logical sector size disk, and this would be an optimal configuration for performance when the disk is hosted on a 4 KB native physical device. Care should be taken to ensure that the guest and the application that is using the virtual disk are backed by the 4 KB logical sector size. The VHDX formatting will work correctly on a 4 KB logical sector size device.

    Block Fragmentation


    Just as the allocations on a physical disk can be fragmented, the allocation of the blocks on a virtual disk can be fragmented when two virtually adjacent blocks are not allocated together on a virtual disk file.

    The fragmentation percentage is reported for disks. If a performance issue noticed on a virtual disk, you should check the fragmentation percentage. When applicable, defragment the virtual disk by creating a new virtual disk with the data from the fragmented disk by using the Create from Source option.


    Pass-through Disks


    The VHD in a virtual machine can be mapped directly to a physical disk or logical unit number (LUN), instead of to a VHD file. The benefit is that this configuration bypasses the NTFS file system in the root partition, which reduces the CPU usage of storage I/O. The risk is that physical disks or LUNs can be more difficult to move between machines than VHD files.

    Large data drives can be prime candidates for pass-through disks, especially if they are I/O intensive. Virtual machines that can be migrated between virtualization servers (such as in a quick migration) must also use drives that reside on a LUN of a shared storage device.


    Advanced Storage Features

    I/O Balancer Controls

    The virtualization stack balances storage I/O streams from different virtual machines so that each virtual machine has similar I/O response times when the system’s I/O bandwidth is saturated. The following registry keys can be used to adjust the balancing algorithm, but the virtualization stack tries to fully use the I/O device’s throughput while providing reasonable balance. The first path should be used for storage scenarios, and the second path should be used for networking scenarios:

    HKLM\System\CurrentControlSet\Services\StorVsp\ = (REG_DWORD)

    Storage and networking have three registry keys at the StorVsp and VmSwitch paths, respectively. Each value is a DWORD and operates as explained in the following list.

    Note   We do not recommend this advanced tuning option unless you have a specific reason to use it. These registry keys may be removed in future releases.

    IOBalance_Enabled

    The balancer is enabled when it is set to a nonzero value, and it is disabled when set to 0. The default is enabled for storage and disabled for networking. Enabling the balancing for networking can add significant CPU overhead in some scenarios.



    IOBalance_KeepHwBusyLatencyTarget_Microseconds

    This controls how much work, represented by a latency value, the balancer allows to be issued to the hardware before throttling to provide better balance. The default is 83 ms for storage and 2 ms for networking. Lowering this value can improve balance, but it will reduce some throughput. Lowering it too much significantly affects overall throughput. Storage systems with high throughput and high latencies can show added overall throughput with a higher value for this parameter.



    IOBalance_AllowedPercentOverheadDueToFlowSwitching

    This controls how much work the balancer issues from a virtual machine before switching to another virtual machine. This setting is primarily for storage where finely interleaving I/Os from different virtual machines can increase the number of disk seeks. The default is 8 percent for both storage and networking.


    NUMA I/O


    Windows Server 2012 supports large virtual machines, and any large virtual machine configuration (for example, a configuration with SQL Server running with 64 virtual processors) will also need scalability in terms of I/O throughput.

    The following key improvements in the Windows Server 2012 storage stack and Hyper-V provide the I/O scalability needs of large virtual machines:



    • An increase in the number of communication channels created between the guest devices and host storage stack

    • A more efficient I/O completion mechanism involving interrupt distribution amongst the virtual processors to avoid interprocessor interruptions, which are expensive

    There are a few registry keys that allow the number of channels to be adjusted. They also align the virtual processors that handle the I/O completions to the virtual CPUs that are assigned by the application to be the I/O processors. The registry values are set on a per-adapter basis on the device’s hardware key. The following two values are located in HKLM\System\CurrentControlSet\Enum\VMBUS\{device id}\{instance id}\Device Parameters\StorChannel

    • ChannelCount (DWORD): The total number of channels to use, with a maximum of 16. It defaults to a ceiling, which is the number of virtual processors/16.

    • ChannelMask (QWORD): The processor affinity for the channels. If it is not set or is set to 0, it defaults to the existing channel distribution algorithm that you use for normal storage or for networking channels. This ensures that your storage channels won’t conflict with your network channels.

    Offloaded Data Transfer Integration


    Crucial maintenance tasks for VHDs, such as merge, move, and compact, depend on copying large amounts of data. The current method of copying data requires data to be read in and written to different locations, which can be a time-consuming process. It also uses CPU and memory resources on the host, which could have been used to service virtual machines.

    Storage area network (SAN) vendors are working to provide near-instantaneous copy operations of large amounts of data. This storage is designed to allow the system above the disks to specify the move of a specific data set from one location to another. This hardware feature is known as an offloaded data transfer.

    The storage stack for HyperV in Windows Server 2012 supports Offload Data Transfer (ODX) operations so that these operations can be passed from the guest operating system to the host hardware. This ensures that the workload can use ODX-enabled storage as it would if it were running in a non-virtualized environment. The HyperV storage stack also issues ODX operations during maintenance operations for VHDs such as merging disks and storage migration meta-operations where large amounts of data are moved.

    Unmap Integration


    Virtual hard disk files exist as files on a storage volume, and they share available space with other files. Because the size of these files tends to be large, the space that they consume can grow quickly. Demand for more physical storage affects the IT hardware budget, so it’s important to optimize the use of physical storage as much as possible.

    Currently, when applications delete content within a virtual hard disk, which effectively abandons the content’s storage space, the Windows storage stack in the guest operating system and the Hyper-V host have limitations that prevent this information from being communicated to the virtual hard disk and the physical storage device. This prevents the Hyper-V storage stack from optimizing the space usage by the VHDX-based virtual disk files. It also prevents the underlying storage device from reclaiming the space that was previously occupied by the deleted data.

    In Windows Server 2012, Hyper-V supports unmap notifications, which allow VHDX files to be more efficient in representing that data within it. This results in smaller files size, and it allows the underlying physical storage device to reclaim unused space.

    Only Hyper-V-specific SCSI, Enlightened IDE and virtual Fibre Channel controllers allow the unmap command from the guest to reach the host virtual storage stack. Hyper-V-specific SCSI is also used for pass-through disks. On the virtual hard disks, only virtual disks formatted as VHDX support unmap commands from the guest.

    For these reasons, we recommend that you use VHDX files attached to a SCSI controller when not using regular pass through or virtual Fibre Channel disks.



    Download 0.61 Mb.
    1   ...   18   19   20   21   22   23   24   25   26




    Download 0.61 Mb.

    Bosh sahifa
    Aloqalar

        Bosh sahifa



    Performance Tuning Guidelines for Windows Server 2012 April 12, 2013 Abstract

    Download 0.61 Mb.