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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
