Already a member?
Sign in
| Version | User | Scope of changes |
|---|---|---|
| Jul 15 2008, 2:49 PM EDT (current) | scott_hanson | 2 words added, 2 words deleted |
| Apr 2 2008, 12:30 PM EDT | todd_muirhead |
Changes
Key: Additions Deletions
This is the wiki homepage for the whitepaper "A Performance Characterization fo Microsoft SQL Server Virtual Machines on Dell PowerEdge Servers Running VMware ESX Server 3.5". This page is summary, for full details download the full whitepaper in PDF form.
In order to understand how Microsoft SQL Server 2005 performs in a virtualized environment, Dell engineers tested both stand alone virtual machines (VMs), multiple VMs, and how these VMs performed during migration from one physical server to another. It was found that performance scaled well when additional processing power was assigned to a VM and when multiple VMs were run on the same server. Additionally the impact of a VMotion migration on a SQL Server VM was minimal, meaning that administrators would be free to use this feature during normal production day – without noticeable impact.
PowerEdge 2950 III Server Hardware Configuration
The initial single VM testing results were used as a starting point for the mulitple VM testing. In the single VM testing, the resources of the 2950 III server were never fully utilized. This was becusae each VM was only assinged up to 4vCPUs and 8 GB of RAM, while the server has a total of 8 cores and 32 GB of RAM. With the mulitple Vm tests some of the configuraitons would commit or overcommit all of the server resources. In these scenarios the test begins to measure teh ability of ESX Server to manage these resources between VMs.
The scaling with the 1vCPU VMs was good. With the 4 1vCPU VM test only half of the total processing power of the server was assigned to VMs, but almost all of the RAM. Linear scalability would have resulted in each of the four VMs individually attaining the same result as the single VM. In this test the average OPM for the four VM case was 10766, which is 12% lower than 12,254 that the single VM achieved. See the below for complete results.
In the 2vCPU tests, scalability remained good as additional VMs were added. In the 4 VM test, all of the processing power and almost all RAM in the server was assigned to VMs. The average OPM for the 4 VM test was 13,470 which is 19% below the 16,939 of the 1 VM test. The next figure shows the complete results for the 2vCPU tests.
With the 4vCPU tests the cores now must be shared between the VMs in the 3 and 4 VM tests. The results are clear in the graph below where the processor becomes the bottleneck in the 3 VM and 4 VM tests. Total OPM does not increase even though each of the VMs has its own memory and disk resources. Each VM achieves aproximately the same performance in all tests. This shows that ESX Server is doing a good job of managing the server resources across the VMs.
The VM was put under moderate stress of about half that used in the performance test, or approximately 40% CPU utilization on the VM. This was done to model an average load, whereas in the performance testing we were trying to model the high end of the acceptable range of utilization.
The time to complete a VMotion is measured from the time the command is issued, until the VM is on the new server. During most of this time, the ESX Servers involved are preparing for the move and the VM remains fully available. It is only at the very end of the VMotion operation, when the VM will actually move, that the VM becomes inaccessible. This time is usually under 1 second and is undetectable to almost all users and applications. Table 4 shows the results for the VMotion testing.
All VMotion migrations completed successfully without errors or warnings. The Windows Event Log and SQL Server error logs were clear of errors as well. The amount of time for a VMotion event to complete did increase when the VM was configured with more vCPUs. This was in part due to the increased workload that was used to keep the test VM at approximately 40% CPU.
The impact of the VMotion events on the performance of the SQL Server VMs was minimal. In order to measure this impact, the VM was run with the same number of threads both with and without VMotion occurring. The difference in the OPM between the two tests is shown in Table 5.
Perhaps the easiest way to see the impact of the VMotion events is in the CPU% of the VM. With each VMotion event there is a slight rise in utilization which can be seen in the figure below.
Please see the full whitepaper for additional details.
Executive Summary
Understanding how applications will perform when used in conjunction with virtualization is important. Many Information Technology (IT) organizations in large and small companies have adopted virtualization technologies to take advantage of management flexibility, cost savings through consolidation, and many other reasons.In order to understand how Microsoft SQL Server 2005 performs in a virtualized environment, Dell engineers tested both stand alone virtual machines (VMs), multiple VMs, and how these VMs performed during migration from one physical server to another. It was found that performance scaled well when additional processing power was assigned to a VM and when multiple VMs were run on the same server. Additionally the impact of a VMotion migration on a SQL Server VM was minimal, meaning that administrators would be free to use this feature during normal production day – without noticeable impact.
Test Configuration
PowerEdge 2950 III Server Hardware Configuration
| Dell PowerEdge 2950 III | |
| Virtualization Software | VMware ESX Server 3.5 |
| CPU | 2 x 3.16 GHz Quad-Core Intel Xeon X5460 with 2x6MB Cache |
| Memory | 32 GB (8 x 4 GB FB DIMMs) |
| Internal Disks | 2 x 146 GB 10K RPM SAS |
| NICs | 2 x 10/100/1000 Mb/s (Internal) |
| Disk Controller | PERC 6/i |
| Fiber Channel HBA | QLogic QLE 2462 – dual port FC4 PCI-Express |
| Remote Management | Dell Remote Access Card, 5th Generation |
Storage Configuration
| Array Controller | 1 Dell|EMC CX3-80 |
| Disk Enclosures | 6 Dell|EMC DAE3P |
| Disks | 99 x 146 GB/ 15K RPM |
| LUNs | 8 10-Disk RAID 1/0 LUNs for Database 4 2-Disk RAID 1 LUNs for Logs 2 5-Disk RAID 5 LUNs for VM Boot Disks 1 HotSpare Disk |
SQL Server 2005 Virtual Machines
| 1 vCPU VM | 2 vCPU VM | 4 vCPU VM | |
| RAM | 8 GB | 8 GB | 8 GB |
| Data Disks | 20 | 20 | 20 |
| Log Disks | 2 | 2 | 2 |
| vCPU | 1 | 2 | 4 |
| vNIC | 1 | 1 | 1 |
Performance Characterization Testing
In order to get a good measure of relative performance, each VM configuration wa measured at 80% CPU utilization. In order to put the CPU utilizaiton to 80% the number of thread specified in the DVD Store driver program was increased while keeping all other parameters the same. The figure below whosshows tehthe results of the testing for a 1vCPU, 2vCPU, and 4vCPU VM.The initial single VM testing results were used as a starting point for the mulitple VM testing. In the single VM testing, the resources of the 2950 III server were never fully utilized. This was becusae each VM was only assinged up to 4vCPUs and 8 GB of RAM, while the server has a total of 8 cores and 32 GB of RAM. With the mulitple Vm tests some of the configuraitons would commit or overcommit all of the server resources. In these scenarios the test begins to measure teh ability of ESX Server to manage these resources between VMs.
The scaling with the 1vCPU VMs was good. With the 4 1vCPU VM test only half of the total processing power of the server was assigned to VMs, but almost all of the RAM. Linear scalability would have resulted in each of the four VMs individually attaining the same result as the single VM. In this test the average OPM for the four VM case was 10766, which is 12% lower than 12,254 that the single VM achieved. See the below for complete results.
In the 2vCPU tests, scalability remained good as additional VMs were added. In the 4 VM test, all of the processing power and almost all RAM in the server was assigned to VMs. The average OPM for the 4 VM test was 13,470 which is 19% below the 16,939 of the 1 VM test. The next figure shows the complete results for the 2vCPU tests.
With the 4vCPU tests the cores now must be shared between the VMs in the 3 and 4 VM tests. The results are clear in the graph below where the processor becomes the bottleneck in the 3 VM and 4 VM tests. Total OPM does not increase even though each of the VMs has its own memory and disk resources. Each VM achieves aproximately the same performance in all tests. This shows that ESX Server is doing a good job of managing the server resources across the VMs.
VMotion Testing
In order create a strenuous VMotion test, the VMs were moved every 12 minutes over a 90 minute period. A Java program using the Virtual Infrastructure SDK was written to automate the VMotion events and ensure they occurred at the same interval for all tests.The VM was put under moderate stress of about half that used in the performance test, or approximately 40% CPU utilization on the VM. This was done to model an average load, whereas in the performance testing we were trying to model the high end of the acceptable range of utilization.
The time to complete a VMotion is measured from the time the command is issued, until the VM is on the new server. During most of this time, the ESX Servers involved are preparing for the move and the VM remains fully available. It is only at the very end of the VMotion operation, when the VM will actually move, that the VM becomes inaccessible. This time is usually under 1 second and is undetectable to almost all users and applications. Table 4 shows the results for the VMotion testing.
| Small VM | Medium VM | Large VM | |
| vCPUs | 1 | 2 | 4 |
| RAM | 8 GB | 8 GB | 8 GB |
| DS2 Driver Threads | 4 | 5 | 8 |
| Avg Time for VMotion (minutes:seconds) | 1:49 | 2:04 | 3:06 |
All VMotion migrations completed successfully without errors or warnings. The Windows Event Log and SQL Server error logs were clear of errors as well. The amount of time for a VMotion event to complete did increase when the VM was configured with more vCPUs. This was in part due to the increased workload that was used to keep the test VM at approximately 40% CPU.
The impact of the VMotion events on the performance of the SQL Server VMs was minimal. In order to measure this impact, the VM was run with the same number of threads both with and without VMotion occurring. The difference in the OPM between the two tests is shown in Table 5.
| Small VM | Medium VM | Large VM | |
| vCPUs | 1 | 2 | 4 |
| RAM | 8 GB | 8 GB | 8 GB |
| DS2 Driver Threads | 4 | 5 | 8 |
| Orders Per Minute with VMotion | 7164 | 8355 | 11312 |
| Orders Per Minute without VMotion | 7556 | 8745 | 12281 |
Perhaps the easiest way to see the impact of the VMotion events is in the CPU% of the VM. With each VMotion event there is a slight rise in utilization which can be seen in the figure below.
Conclusions
The performance of SQL Server 2005 running within a VM on VMware ESX Server 3.5 on a Dell server is very good. Within a VM, performance scaled over 50% when doubling the number of virtual processors from 2 to 4. Performance was near linear when adding additional VMs. Additionally, it was easy to use VMotion to move a VM from one physical server to another while under load. During that process the performance of that VM was only slightly impacted. If a VM is properly sized with enough disk resources, the performance of SQL Server 2005 remains good as additional resources are added, up to the maximum level of the server.Please see the full whitepaper for additional details.
