Random Notes
  • Introduction
  • Reading list
  • Theory
    • Index
      • Impossibility of Distributed Consensus with One Faulty Process
      • Time, Clocks, and the Ordering of Events in a Distributed System
      • Using Reasoning About Knowledge to analyze Distributed Systems
      • CAP Twelve Years Later: How the “Rules” Have Changed
      • A Note on Distributed Computing
  • Operating System
    • Index
  • Storage
    • Index
      • Tachyon: Reliable, Memory Speed Storage for Cluster Computing Frameworks
      • Exploiting Commutativity For Practical Fast Replication
      • Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS
      • Building Consistent Transactions with Inconsistent Replication
      • Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System
      • Spanner: Google's Globally-Distributed Database
      • Bigtable: A Distributed Storage System for Structured Data
      • The Google File System
      • Dynamo: Amazon’s Highly Available Key-value Store
      • Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications
      • Replicated Data Consistency Explained Through Baseball
      • Session Guarantees for Weakly Consistent Replicated Data
      • Flat Datacenter Storage
      • Small Cache, Big Effect: Provable Load Balancing forRandomly Partitioned Cluster Services
      • DistCache: provable load balancing for large-scale storage systems with distributed caching
      • Short Summaries
  • Coordination
    • Index
      • Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases
      • Paxos made simple
      • ZooKeeper: Wait-free coordination for Internet-scale systems
      • Just Say NO to Paxos Overhead: Replacing Consensus with Network Ordering
      • Keeping CALM: When Distributed Consistency is Easy
      • In Search of an Understandable Consensus Algorithm
      • A comprehensive study of Convergent and Commutative Replicated Data Types
  • Fault Tolerance
    • Index
      • The Mystery Machine: End-to-end Performance Analysis of Large-scale Internet Services
      • Gray Failure: The Achilles’ Heel of Cloud-Scale Systems
      • Capturing and Enhancing In Situ System Observability for Failure Detection
      • Check before You Change: Preventing Correlated Failures in Service Updates
      • Efficient Scalable Thread-Safety-Violation Detection
      • REPT: Reverse Debugging of Failures in Deployed Software
      • Redundancy Does Not Imply Fault Tolerance
      • Fixed It For You:Protocol Repair Using Lineage Graphs
      • The Good, the Bad, and the Differences: Better Network Diagnostics with Differential Provenance
      • Lineage-driven Fault Injection
      • Short Summaries
  • Cloud Computing
    • Index
      • Improving MapReduce Performance in Heterogeneous Environments
      • CLARINET: WAN-Aware Optimization for Analytics Queries
      • MapReduce: Simplified Data Processing on Large Clusters
      • Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
      • Resource Management
      • Apache Hadoop YARN: Yet Another Resource Negotiator
      • Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center
      • Dominant Resource Fairness: Fair Allocation of Multiple Resource Types
      • Large-scale cluster management at Google with Borg
      • MapReduce Online
      • Delay Scheduling: A Simple Technique for Achieving Locality and Fairness in Cluster Scheduling
      • Reining in the Outliers in Map-Reduce Clusters using Mantri
      • Effective Straggler Mitigation: Attack of the Clones
      • Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing
      • Discretized Streams: Fault-Tolerant Streaming Computation at Scale
      • Sparrow: Distributed, Low Latency Scheduling
      • Making Sense of Performance in Data Analytics Framework
      • Monotasks: Architecting for Performance Clarity in Data Analytics Frameworks
      • Drizzle: Fast and Adaptable Stream Processing at Scale
      • Naiad: A Timely Dataflow System
      • The Dataflow Model:A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale
      • Interruptible Tasks:Treating Memory Pressure AsInterrupts for Highly Scalable Data-Parallel Program
      • PACMan: Coordinated Memory Caching for Parallel Jobs
      • Multi-Resource Packing for Cluster Schedulers
      • Other interesting papers
  • Systems for ML
    • Index
      • A Berkeley View of Systems Challenges for AI
      • Tiresias: A GPU Cluster Managerfor Distributed Deep Learning
      • Gandiva: Introspective Cluster Scheduling for Deep Learning
      • Workshop papers
      • Hidden Technical Debt in Machine Learning Systems
      • Inference Systems
      • Parameter Servers and AllReduce
      • Federated Learning at Scale - Part I
      • Federated Learning at Scale - Part II
      • Learning From Non-IID data
      • Ray: A Distributed Framework for Emerging AI Applications
      • PipeDream: Generalized Pipeline Parallelism for DNN Training
      • DeepXplore: Automated Whitebox Testingof Deep Learning Systems
      • Distributed Machine Learning Misc.
  • ML for Systems
    • Index
      • Short Summaries
  • Machine Learning
    • Index
      • Deep Learning with Differential Privacy
      • Accelerating Deep Learning via Importance Sampling
      • A Few Useful Things to Know About Machine Learning
  • Video Analytics
    • Index
      • Scaling Video Analytics on Constrained Edge Nodes
      • Focus: Querying Large Video Datasets with Low Latency and Low Cost
      • NoScope: Optimizing Neural Network Queriesover Video at Scale
      • Live Video Analytics at Scale with Approximation and Delay-Tolerance
      • Chameleon: Scalable Adaptation of Video Analytics
      • End-to-end Learning of Action Detection from Frame Glimpses in Videos
      • Short Summaries
  • Networking
    • Index
      • Salsify: Low-Latency Network Video through Tighter Integration between a Video Codec and a Transport
      • Learning in situ: a randomized experiment in video streaming
      • Short Summaries
  • Serverless
    • Index
      • Serverless Computing: One Step Forward, Two Steps Back
      • Encoding, Fast and Slow: Low-Latency Video Processing Using Thousands of Tiny Threads
      • SAND: Towards High-Performance Serverless Computing
      • Pocket: Elastic Ephemeral Storage for Serverless Analytics
      • Fault-tolerant and Transactional Stateful Serverless Workflows
  • Resource Disaggregation
    • Index
  • Edge Computing
    • Index
  • Security/Privacy
    • Index
      • Differential Privacy
      • Honeycrisp: Large-Scale Differentially Private Aggregation Without a Trusted Core
      • Short Summaries
  • Misc.
    • Index
      • Rate Limiting
      • Load Balancing
      • Consistency Models in Distributed System
      • Managing Complexity
      • System Design
      • Deep Dive into the Spark Scheduler
      • The Actor Model
      • Python Global Interpreter Lock
      • About Research and PhD
Powered by GitBook
On this page
  • TL;DR:
  • Motivation:
  • Summary:
  • Delay Assignment:
  • Evaluation:
  • Related Works:
  • Related Links:

Was this helpful?

  1. Cloud Computing
  2. Index

Effective Straggler Mitigation: Attack of the Clones

https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final231.pdf

TL;DR:

This paper presents Dolly, a system that launches multiple clones tasks in jobs, completely removing waiting from straggler mitigation. Evaluation using production workloads showed that Dolly speeds up small jobs by 34% to 46% on average using only 5% extra resources.[1]

Motivation:

Stragglers are tasks that run much slower than other tasks, thus increasing the latency of the corresponding jobs. Techniques of straggler mitigation can be broadly divided into two classes: black-listing and speculative execution. (See related work for details). However, the paper shows that even after applying the state-fo-the-art techniques, the small jobs still have stragglers, on average, run 8x slower than that job's median task, slowing them by 47% on average.

Note that this paper mainly focus on small interactive jobs consist of just a few tasks[2], because both existing straggler mitigation techniques(e.g. LATE and Mantri) effectively mitigate stragglers in large jobs.

Summary:

The paper proposes an approach that proactively launches clones of a job, just as they are submitted, and picks the result from the earliest clone. Cloning comes with two main challenges:

  • Extra clones might use a prohibitive amount of extra resources.

First, based on analysis of production traces, the smallest 90% of jobs consume as less as 6% of the resources. In addition, to guarantee that Dolly doesn't use too much resource, the scheduler will run a Budget Cloning Algorithm[3].

  • Contention in reading intermediate data[4].

To deal with contention, we have two straw-man solutions:

Contention-Avoidance Cloning(CAC): The first option eschews contention altogether. The output of an upstream task is sent to exactly one downstream task clone. Thus, the other downstream task clones have to wait for other upstream tasks to finish. The upstream stragglers will make the corresponding downstream task lag behind. Experiments show that straggler probability in a job increases by >10%

Contention Cloning(CC): The second option makes all tasks in a downstream clone group read the output of the upstream clone that finishes first. However, all of the downstream task clones may slow down due to contention on disk or network bandwidth. Not surprisingly, intermediate data transfer takes ~50% longer.

Delay Assignment:

Dolly adopts a hybrid approach, similar to delay scheduling, that adds small delay to get exclusive copy before contending for the available copy. Delay is updated automatically and periodically

Evaluation:

Dolly improves the average completion time of small jobs by 34% and 46% compare to LATE and Mantri, using fewer than 5% extra resources. In addition, Delay assignment outperforms CAC and CC by 2x.

[1] After applying LATE and Mantri

[2] In Facebook, 88% of jobs operate on 20GB of data and contain fewer than 50 tasks

[3] Cloning is avoided if the cluster utilization after spawning clones will be exceed the allotted resources. The algorithm makes sure that Dolly will operate within an allotted resource budget. See section 3.2 for more details.

[4] Note that reading the input data is not a problem since the input data is replicated three times (typically) by file system and . Thus, each clone should be able to get its own copy of data. However, to avoid overheads, Intermediate data is not replicated at all.

Related Works:

The problem of stragglers has received considerable attention already. I'll list some existing techniques and explain why they don't work well in small jobs.

Blacklisting identifies machines in bad health(e.g. erroneous) and avoid scheduling tasks on them. However, stragglers can still occur on the non-blacklisted machines, for complex reasons like IO contentions and interference by periodic maintenance operations.

Speculative execution measures relative progress of tasks of a job and launch duplicative/speculative copies of straggler tasks. Examples of such include LATE and Mantri). However, they are ill-suited to address stragglers in small jobs, because 1. small jobs consist of just a few tasks 2. Observing might constitutes large fraction of job’s duration.

Related Links:

PreviousReining in the Outliers in Map-Reduce Clusters using MantriNextResilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

Last updated 5 years ago

Was this helpful?

LogoEffective Straggler Mitigation: Attack of the Clones | USENIX