# A Framework for Proactive Resource Provisioning in IaaS Clouds
## 4 Experimental Results  
A small-scale cloud system including 3 servers is built for experiments. Table 1 lists the hardware specification of the 3 servers. The OS of physical machines is Ubuntu 13.04 (www.ubuntu.com), and the hypervisor is KVM 3.5.0-23 (www.linux-kvm.org). The cloud OS is OpenStack (Grizzly, www.openstack.org), and Apache Mesos 1.1.0 (mesos.apache.org) is used to supply the virtual clusters in which virtual resources may be obtained from multiple physical servers. Apache Spark 1.5.0 (spark.apache.org) is adopted as the data processing platform. In this virtual cluster computing system, each virtual machine occupies 4 vCPU, 4 GB RAM, and 40 GB disk. In each virtual machine, the Spark executor occupies one vCPU, and other vCPUs are used to execute tasks of applications. That is, when the virtual machine has \(m\) vCPU, the virtual machine could execute \(m-1\) Spark tasks at most. Figure 5: Pseudo-code of proposed proactive critical task scheduling algorithm. In Figures 6-10, SparkTC is executed 5 iterations successively to demonstrate the variations of physical resource utilization. The numbers of nodes and edges in executing SparkTC are set to 100  
Figure 8: Resource utilization of executing SparkTC when over-commit with 16 vCPU demands. Figure 10: Resource utilization of executing SparkTC when over-commit with 64 vCPU demands. Figure 9: Resource utilization of executing SparkTC when over-commit with 32 vCPU demands. and 150. When the degree of over-commit is 1, which means there is no over-committed resource provisioning, each virtual machine has 4 vCPUs and each vCPU corresponds to a physical CPU core. The execution time is 5611 s as shown in Figure 6, because the number of tasks that Spark submitted to execute in parallel is very limited. In Figures 7-10, the degree of over-commit is set to 2, 4, 8, and 16, respectively. That is, each virtual machine is over-committed to 8, 16, 32, and 64 vCPUs, respectively, but the number of physical CPU cores is still 4. This over-commit setting lets Spark believe there are many available resources, and then submits more tasks to compete for physical CPU cores. As shown in Figures 7-10, when the degree of over-commit increases, the execution time of SparkTC is reduced to 2509, 1189, 727, and 573 s. Apparently, applying the over-commit mechanism makes the CPU utilization increase and results in shorter execution time. In the meantime, the CPU utilization of executing SparkTC without over-committed resources is about 10%. When the degree of over-commit increases, experimental results show that the CPU utilization also increases accordingly. For example, in Figure 10, the range of CPU utilizations of executing SparkTC with 64 over-committed vCPUs is about 20% to 60%. However, although the amount of provisioned resources exceeds the actual needs in executing SparkTC, the utilization of memory is rarely changed as the provisioned resource increases. The reason is that SparkTC is a computing-sensitive application and the amount of required memory is stable. Figure 11 shows the execution time of SparkTC when the degrees of over-commit are 1 and 16 (i.e., without and with (64 vCPU) over-committed resources). In this figure, the number of nodes remains 100, and the number of edges are 150, 300, 600, 900, and 1200. Since the number of nodes is fixed, when the number of edges increases, the graph topology of SparkTC changes from sparse to dense. The main step in micro-benchmark SparkTC is to check whether there is a path from node \(x\) to node \(z\) through node \(y\). When the graph topology becomes denser, it is reasonable that the probability of finding such paths increases and the execution time of SparkTC decreases. Figure 11 also shows that the execution time after applying the over-commit approach is much shorter than without applying over-committed resources. Figure 12 shows the execution time of SparkLR when the degrees of over-commit are 1 and 16 (i.e., without and with (64 vCPU) over-committed resources).