Jockey

Abstract

Data processing frameworks such as MapReduce [8] and Dryad [11] are used today in business environments where customers expect guaranteed performance. To date, however, these systems are not capable of providing guarantees on job latency because scheduling policies are based on fairsharing, and operators seek high cluster use through statistical multiplexing and over-subscription. With Jockey, we provide latency SLOs for data parallel jobs written in SCOPE. Jockey precomputes statistics using a simulator that captures the job's complex internal dependencies, accurately and efficiently predicting the remaining run time at different resource allocations and in different stages of the job. Our control policy monitors a job's performance, and dynamically adjusts resource allocation in the shared cluster in order to maximize the job's economic utility while minimizing its impact on the rest of the cluster. In our experiments in Microsoft's production Cosmos clusters, Jockey meets the specified job latency SLOs and responds to changes in cluster conditions.

PB3Opt: Profile‐based biased Bayesian optimization to select computing clusters on the cloud

“…1,2,6,7 Thus, finding and matching the best cloud provider and best VM configuration to cost-efficiently run a workload became an important problem that has been approached by many authors. 2,3,[7][8][9][10] Moreover, the cloud infrastructure is dynamic 11 and can have a high variation in performance, 12 mostly because of the concurrent use of the physical resources from different VMs and users. Thus, the profiling collected from one run may not reflect a later one.…”

Feedback Autonomic Provisioning for Guaranteeing Performance in MapReduce Systems

“…Vianna et al [44] propose a hierarchical model that combines a precedence graph with a queueing network to model the intra-job synchronisation constraints. Some as Jockey [45] use a simulator that captures the complex interdependencies of a job and makes use of previous runtime statistics to predict job runtime. On the opposite side there are the regression and black box models.…”

“…ARIA can, at run time, allocate the appropriate resources (slots) to a job so that the job meets its time constraints. Jockey [45] monitors job performance and dynamically adjusts its resources to maximise economic utility, while minimising its impact on the rest of the cluster. While all the previous approaches propose fine grained job level performance control at a scheduler level, we propose to add course grained control by controlling the average performance of a group of jobs in the cluster.…”

Mary, Hugo, and Hugo*: Learning to schedule distributed data‐parallel processing jobs on shared clusters

“…That is, few jobs utilize resources well for the entirety of their runtimes, making it beneficial to co‐locate multiple jobs onto shared resources, since the combined resource utilization of multiple co‐located jobs often fluctuates less. Moreover, to further increase resource utilization, one often‐applied strategy is to oversubscribe resources to a certain extent when scheduling jobs onto cluster resources 26 . However, since jobs differ considerably in which resources they stress and how much their resource utilization fluctuates, it can make a significant difference in terms of overall resource utilization and makespan which specific combinations of jobs share resources.…”

“…Therefore, schedulers should actively co‐locate those jobs that share resources efficiently. The benefits of such approaches have been demonstrated before with multiple schedulers that explicitly take combined resource utilization and interference among co‐located workloads into account 11,18,27 or learn the impact of this indirectly, 28,29 taking advantage of the recurrence of a majority of jobs in industry workloads 21,26 …”