To test PARDA with more realistic enterprise workloads, we experimented with two Windows Server 2003 VMs, each running a Microsoft SQL Server 2005 Enterprise Edition database. Each VM is configured with 4 virtual CPUs, 6.4 GB of RAM, a 10 GB system disk, a 250 GB database disk, and a 50 GB log disk. The database virtual disks are hosted on an 800 GB RAID-0 LUN with 6 disks; log virtual disks are placed on a 100 GB RAID-0 LUN with 10 disks. We used the Dell DVD store (DS2) database test suite, which implements a complete online e-commerce application, to stress the SQL databases [7]. We configured a 15 ms latency threshold, and ran one VM per host, assigning shares in a ratio.
Table 7 reports the parameters and the overall application performance for the two SQL Server VMs. Without PARDA, both VMs have similar performance in terms of both orders per minute (OPM) and average latency. When running with PARDA, the VM with higher shares obtains roughly twice the OPM throughput and half the average latency. The ratio isn't because the workloads are not always backlogged, and the VM with higher shares can't keep its window completely full.
Figure 14 plots the window size, latency and throughput observed by the hosts. As the overall latency decreases, PARDA is able to assign high window sizes to both hosts. When latency increases, the window sizes converge to be approximately proportional to the values. Figure 15 shows the values for the hosts while the workload is running, and highlights the fact that the SQL Server VM on host 2 cannot always maintain enough pending IOs to fill its window. This causes the other VM on host 1 to pick up the slack and benefit from increased IO throughput.
|
Ajay Gulati 2009-01-14