Applications Know Best: Performance-Driven Memory Overcommit with Ginkgo

Abstract

Abstract-Memory overcommitment enables cloud providers to host more virtual machines on a single physical server, exploiting spare CPU and I/O capacity when physical memory becomes the bottleneck for virtual machine deployment. However, overcommiting memory can also cause noticeable application performance degradation. We present Ginkgo, a policy framework for overcomitting memory in an informed and automated fashion. By directly correlating application-level performance to memory, Ginkgo automates the redistribution of scarce memory across all virtual machines, satisfying performance and capacity constraints. Ginkgo also achieves memory gains for traditionally fixed-size Java applications by coordinating the redistribution of available memory with the activities of the Java Virtual Machine heap. When compared to a non-overcommited system, Ginkgo runs the DayTrader 2.0 and SPECWeb 2009 benchmarks with the same number of virtual machines while saving up to 73% (50% omitting free space) of a physical server's memory while keeping application performance degradation within 7%.

On Cloud-based Oversubscription

“…As the cloud gains in popularity, network traffic continues to increase which can lead to bottlenecks and latency [19][20]. Jain et al [17] focus on remediating overload using VM migration in a tree topology data center network. They are the first to concurrently consider load constraints of servers and the traffic capacity constraints of the tree edges.…”

Automatic memory-based vertical elasticity and oversubscription on cloud platforms

“…In [10], the Ginkgo memory overcommitting framework is introduced, which dynamically estimates VM memory requirements for applications and automates the distribution of memory across VMs through ballooning techniques. It uses performance profiles of the applications to characterise incoming load.…”

The judgment of forseti: economic utility for dynamic heap sizing of multiple runtimes

“…They acknowledge that they are only providing a mechanism for memory resource allocation, without any specific allocation policy. Ginkgo [13] presents another JVM ballooning policy based on JNI, with a set of resource allocation constraints induced by service level agreements and solved with linear programming. Kim et al [14] describe an approach to handle memory resource allocation for an isolated group of VMs, which may be subject to a common service level agreement.…”