Github user kayousterhout commented on a diff in the pull request:
https://github.com/apache/spark/pull/14079#discussion_r86468669
--- 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()
+ val expiryTime = now + BLACKLIST_TIMEOUT_MILLIS
+ failuresByExec.foreach { case (exec, failuresInTaskSet) =>
+ val allFailuresOnOneExecutor =
+ executorIdToFailureList.getOrElseUpdate(exec, new
ExecutorFailureList)
+ // Apply the timeout to individual tasks. This is to prevent
one-off failures that are very
+ // spread out in time (and likely have nothing to do with problems
on the executor) from
+ // triggering blacklisting. However, note that we do *not* remove
executors and nodes from
+ // the blacklist as we expire individual task failures -- each have
their own timeout. Eg.,
+ // suppose:
+ // * timeout = 10, maxFailuresPerExec = 2
+ // * Task 1 fails on exec 1 at time 0
+ // * Task 2 fails on exec 1 at time 5
+ // --> exec 1 is blacklisted from time 5 - 15.
+ // This is to simplify the implementation, as well as keep the
behavior easier to understand
+ // for the end user.
+ allFailuresOnOneExecutor.dropFailuresWithTimeoutBefore(now)
+ allFailuresOnOneExecutor.addFailures(stageId, stageAttemptId,
failuresInTaskSet)
+ val newTotal = allFailuresOnOneExecutor.numUniqueTaskFailures
+
+ if (newTotal >= MAX_FAILURES_PER_EXEC) {
+ logInfo(s"Blacklisting executor id: $exec because it has
$newTotal" +
+ s" task failures in successful task sets")
+ val node = failuresInTaskSet.node
+ executorIdToBlacklistStatus.put(exec, BlacklistedExecutor(node,
expiryTime))
+ executorIdToFailureList.remove(exec)
--- End diff --
It seems like one weird thing that can happen here is:
- Executor 1 gets blacklisted
- Some tasks for other task sets are still running on executor 1, and some
of those tasks fail
- Enough of those tasks fail that when updateBlacklistForSuccessfulTaskSet
is called for those task sets, executor 1 is re-blacklisted.
It seems like this is fine -- the entry in executorIdToBlacklistStatus will
get updated with a new time -- right?
And then nodeIdToBlacklistExpiryTime will also be updated with the new
time, so the assumption in updateNextExpiryTime, that a node's expiry time will
always coincide with an executor's expiry time, will still hold.
The only case I can think of when things might go awry is if one of the
*other* executors that had a failure on the node (in nodeToBlacklistedExecs)
expires in between the first time executor 1 gets blacklisted and when it's
re-blacklisted. In that case, the node wouldn't get re-blacklisted, so the
assumption in updateNextExpiryTime won't hold. Does that seem right? Does it
seem worth eliminating that assumption from updateNextExpiryTime?
Also, I wonder if it makes sense to *not* remove the executor from
executorIdToFailureList here, since it does seem like it leads to kind of weird
behavior -- where the executor is only re-blacklisted if MAX_FAILURES_PER_EXEC
more failures happen (as opposed to if just 1 more failure happens). But maybe
that has memory leak issues?
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
