Check out the new USENIX Web site.

Enterprise Workloads

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 $ 1:4$ 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 $ 1:4$ 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 $ \beta $ values. Figure 15 shows the $ \beta $ 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.


Table 7: Two SQL Server VMs with $ 1:4$ share ratio, running with and without PARDA. Host weights ($ \beta _h$ ) and OPM (orders/min), IOPS ($ T_h$ for hosts) and latencies ($ Avg Lat$ for database operations, $ L_h$ for hosts, in ms). $ \cal {L}$ = 15 ms, $ w_{max}$ = 32.

Uncontrolled PARDA
Host VM Type $ OPM$ $ Avg Lat$ $ T_{h}$ , $ L_{h}$ $ \beta_{h}$ $ OPM$ $ Avg Lat$
1 SQL1 8799 213 615, 20.4 1 6952 273
2 SQL2 8484 221 588, 20.5 4 12356 151


Figure 14: Enterprise Workload. Host window sizes and IOPS for SQL Server VMs are proportional to their overall $ \beta $ values whenever the array resources are contended. Between $ t=300$  s and $ t=380$  s, hosts get larger window sizes since the array is not contended.

\epsfig{figure=plots/sql-exp2-ws.ps,height=1.6in}

\epsfig{figure=plots/sql-exp2-lat.ps,height=1.6in}

\epsfig{figure=plots/sql-exp2-th.ps,height=1.6in}

(a) Window Size (b) Latency (ms) (c) Throughput (IOPS)
Figure 15: Dynamic $ \beta $ Adjustment. $ \beta $ values for hosts running SQL Server VMs fluctuate as pending IO counts change.
\begin{figure}\centerline{
\hspace{-0.3in}
\psfig{figure=plots/sql-exp2-beta.ps,height=1.6in,} \ }
\vspace{-0.17in}\vspace{-0.1in}
\end{figure}

Ajay Gulati 2009-01-14