spark-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kayousterhout <...@git.apache.org>
Subject [GitHub] spark pull request #14079: [SPARK-8425][CORE] Application Level Blacklisting
Date Tue, 13 Dec 2016 06:23:24 GMT
Github user kayousterhout commented on a diff in the pull request:

    https://github.com/apache/spark/pull/14079#discussion_r90543538
  
    --- Diff: core/src/main/scala/org/apache/spark/scheduler/BlacklistTracker.scala ---
    @@ -17,10 +17,254 @@
     
     package org.apache.spark.scheduler
     
    +import java.util.concurrent.atomic.AtomicReference
    +
    +import scala.collection.mutable.{ArrayBuffer, HashMap, HashSet}
    +
     import org.apache.spark.SparkConf
     import org.apache.spark.internal.Logging
     import org.apache.spark.internal.config
    -import org.apache.spark.util.Utils
    +import org.apache.spark.util.{Clock, SystemClock, Utils}
    +
    +/**
    + * BlacklistTracker is designed to track problematic executors and nodes.  It supports
blacklisting
    + * executors and nodes across an entire application (with a periodic expiry).  TaskSetManagers
add
    + * additional blacklisting of executors and nodes for individual tasks and stages which
works in
    + * concert with the blacklisting here.
    + *
    + * The tracker needs to deal with a variety of workloads, eg.:
    + *
    + *  * bad user code --  this may lead to many task failures, but that should not count
against
    + *      individual executors
    + *  * many small stages -- this may prevent a bad executor for having many failures within
one
    + *      stage, but still many failures over the entire application
    + *  * "flaky" executors -- they don't fail every task, but are still faulty enough to
merit
    + *      blacklisting
    + *
    + * See the design doc on SPARK-8425 for a more in-depth discussion.
    + *
    + * THREADING: As with most helpers of TaskSchedulerImpl, this is not thread-safe.  Though
it is
    + * called by multiple threads, callers must already have a lock on the TaskSchedulerImpl.
 The
    + * one exception is [[nodeBlacklist()]], which can be called without holding a lock.
    + */
    +private[scheduler] class BlacklistTracker (
    +    conf: SparkConf,
    +    clock: Clock = new SystemClock()) extends Logging {
    +
    +  BlacklistTracker.validateBlacklistConfs(conf)
    +  private val MAX_FAILURES_PER_EXEC = conf.get(config.MAX_FAILURES_PER_EXEC)
    +  private val MAX_FAILED_EXEC_PER_NODE = conf.get(config.MAX_FAILED_EXEC_PER_NODE)
    +  val BLACKLIST_TIMEOUT_MILLIS = BlacklistTracker.getBlacklistTimeout(conf)
    +
    +  /**
    +   * A map from executorId to information on task failures.  Tracks the time of each
task failure,
    +   * so that we can avoid blacklisting executors due to failures that are very far apart.
 We do not
    +   * actively remove from this as soon as tasks hit their timeouts, to avoid the time
it would take
    +   * to do so.  But it will not grow too large, because as soon as an executor gets too
many
    +   * failures, we blacklist the executor and remove its entry here.
    +   */
    +  private val executorIdToFailureList = new  HashMap[String, ExecutorFailureList]()
    +  val executorIdToBlacklistStatus = new HashMap[String, BlacklistedExecutor]()
    +  val nodeIdToBlacklistExpiryTime = new HashMap[String, Long]()
    +  /**
    +   * An immutable copy of the set of nodes that are currently blacklisted.  Kept in an
    +   * AtomicReference to make [[nodeBlacklist()]] thread-safe.
    +   */
    +  private val _nodeBlacklist = new AtomicReference[Set[String]](Set())
    +  /**
    +   * Time when the next blacklist will expire.  Used as a
    +   * shortcut to avoid iterating over all entries in the blacklist when none will have
expired.
    +   */
    +  var nextExpiryTime: Long = Long.MaxValue
    +  /**
    +   * Mapping from nodes to all of the executors that have been blacklisted on that node.
We do *not*
    +   * remove from this when executors are removed from spark, so we can track when we
get multiple
    +   * successive blacklisted executors on one node.  Nonetheless, it will not grow too
large because
    +   * there cannot be many blacklisted executors on one node, before we stop requesting
more
    +   * executors on that node, and we periodically clean up the list of blacklisted executors.
    +   */
    +  val nodeToBlacklistedExecs = new HashMap[String, HashSet[String]]()
    +
    +  /**
    +   * Un-blacklists executors and nodes that have been blacklisted for at least
    +   * BLACKLIST_TIMEOUT_MILLIS
    +   */
    +  def applyBlacklistTimeout(): Unit = {
    +    val now = clock.getTimeMillis()
    +    // quickly check if we've got anything to expire from blacklist -- if not, avoid
doing any work
    +    if (now > nextExpiryTime) {
    +      // Apply the timeout to blacklisted nodes and executors
    +      val execsToUnblacklist = executorIdToBlacklistStatus.filter(_._2.expiryTime <
now).keys
    +      if (execsToUnblacklist.nonEmpty) {
    +        // Un-blacklist any executors that have been blacklisted longer than the blacklist
timeout.
    +        logInfo(s"Removing executors $execsToUnblacklist from blacklist because the blacklist
" +
    +          s"for those executors has timed out")
    +        execsToUnblacklist.foreach { exec =>
    +          val status = executorIdToBlacklistStatus.remove(exec).get
    +          val failedExecsOnNode = nodeToBlacklistedExecs(status.node)
    +          failedExecsOnNode.remove(exec)
    +          if (failedExecsOnNode.isEmpty) {
    +            nodeToBlacklistedExecs.remove(status.node)
    +          }
    +        }
    +      }
    +      val nodesToUnblacklist = nodeIdToBlacklistExpiryTime.filter(_._2 < now).keys
    +      if (nodesToUnblacklist.nonEmpty) {
    +        // Un-blacklist any nodes that have been blacklisted longer than the blacklist
timeout.
    +        logInfo(s"Removing nodes $nodesToUnblacklist from blacklist because the blacklist
" +
    +          s"has timed out")
    +        nodesToUnblacklist.foreach { node => nodeIdToBlacklistExpiryTime.remove(node)
}
    +        _nodeBlacklist.set(nodeIdToBlacklistExpiryTime.keySet.toSet)
    +      }
    +      updateNextExpiryTime()
    +    }
    +  }
    +
    +  private def updateNextExpiryTime(): Unit = {
    +    // we don't need to check nodeIdToBlacklistExpiryTime because that will always share
an
    +    // expiry time with some blacklisted executor.  In other words, the next node expiry
time
    +    // will never be before the next executor blacklist time.
    +    if (executorIdToBlacklistStatus.nonEmpty) {
    +      nextExpiryTime = executorIdToBlacklistStatus.map{_._2.expiryTime}.min
    +    } else {
    +      nextExpiryTime = Long.MaxValue
    +    }
    +  }
    +
    +
    +  def updateBlacklistForSuccessfulTaskSet(
    +      stageId: Int,
    +      stageAttemptId: Int,
    +      failuresByExec: HashMap[String, ExecutorFailuresInTaskSet]): Unit = {
    +    // if any tasks failed, we count them towards the overall failure count for the executor
at
    +    // this point.
    +    val now = clock.getTimeMillis()
    --- End diff --
    
    Here's what I was concerned about:
    
    Suppose BLACKLIST_TIMEOUT_MILLIS is 5 and MAX_FAILURES_PER_EXEC is 2.
    
    In a long running task set, task set 0, a task fails on executor A at time 8, but the
blacklist tracker doesn't find out about this until much later when the task set finishes
(for the sake of example, time 100).
    
    In the meantime task set 1 runs, has a task that fails on executor A at time 98, and then
completes shortly thereafter at time 99.
    
    At this point, there have been two failures on executor A: one at time 8 and one at time
98.  These are so far apart that they shouldn't cause A to be blacklisted.  But it looks like
when task set 0 finishes, we'll still add the entry at time 8 to ExecutorFailureList, and
then hit MAX_FAILURES_PER_EXEC and blacklist executor A.  This seems overly aggressive (i.e.,
it seems like long-running task sets can "unfairly" get executors to be blacklisted that actually
had very spread out failures, potentially far in the past).
    
    It looks like this could be fixed by swapping lines 150 and 151 (with a comment that this
is to handle long task sets)?  I think this is what you were saying seems confusing, but I
think is necessary to avoid blacklisting behavior that seems inconsistent with the timeout.
 Let me know if I'm misinterpreting the behavior here!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org


Mime
View raw message