[
https://issues.apache.org/jira/browse/SPARK-21084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hyukjin Kwon resolved SPARK-21084.
----------------------------------
Resolution: Incomplete
> Improvements to dynamic allocation for notebook use cases
> ---------------------------------------------------------
>
> Key: SPARK-21084
> URL: https://issues.apache.org/jira/browse/SPARK-21084
> Project: Spark
> Issue Type: Umbrella
> Components: Block Manager, Scheduler, Spark Core, YARN
> Affects Versions: 2.2.0, 2.3.0
> Reporter: Frederick Reiss
> Priority: Major
> Labels: bulk-closed
>
> One important application of Spark is to support many notebook users with a
> single YARN or Spark Standalone cluster. We at IBM have seen this
> requirement across multiple deployments of Spark: on-premises and private
> cloud deployments at our clients, as well as on the IBM cloud. The scenario
> goes something like this: "Every morning at 9am, 500 analysts log into their
> computers and start running Spark notebooks intermittently for the next 8
> hours." I'm sure that many other members of the community are interested in
> making similar scenarios work.
>
> Dynamic allocation is supposed to support these kinds of use cases by
> shifting cluster resources towards users who are currently executing scalable
> code. In our own testing, we have encountered a number of issues with using
> the current implementation of dynamic allocation for this purpose:
> *Issue #1: Starvation.* A Spark job acquires all available containers,
> preventing other jobs or applications from starting.
> *Issue #2: Request latency.* Jobs that would normally finish in less than 30
> seconds take 2-4x longer than normal with dynamic allocation.
> *Issue #3: Unfair resource allocation due to cached data.* Applications that
> have cached RDD partitions hold onto executors indefinitely, denying those
> resources to other applications.
> *Issue #4: Loss of cached data leads to thrashing.* Applications repeatedly
> lose partitions of cached RDDs because the underlying executors are removed;
> the applications then need to rerun expensive computations.
>
> This umbrella JIRA covers efforts to address these issues by making
> enhancements to Spark.
> Here's a high-level summary of the current planned work:
> * [SPARK-21097]: Preserve an executor's cached data when shutting down the
> executor.
> * [SPARK-21122]: Make Spark give up executors in a controlled fashion when
> the RM indicates it is running low on capacity.
> * (JIRA TBD): Reduce the delay for dynamic allocation to spin up new
> executors.
> Note that this overall plan is subject to change, and other members of the
> community should feel free to suggest changes and to help out.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
