[
https://issues.apache.org/jira/browse/SPARK-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152744#comment-14152744
]
Aaron Davidson commented on SPARK-1860:
---------------------------------------
Note that there are two separate forms of cleanup: application data cleanup
(jars and logs) and shuffle data cleanup. Standalone Worker cleanup deals with
the former, Executor termination handlers deal with the latter. The purpose is
not to deal with executors that have terminated ungracefully, but to actually
clean up old application directories.
Here the idea is that a Worker may be running for a very long time (weeks,
months) and over time accumulates hundreds of application directories. We want
to delete these directories after several days of them being terminated (today
we'll clean them up whether or not they're terminated, which loses their jars
and logs), after which we presumably don't care anymore. We do not want to
clean them up immediately after application termination.
The Worker performing shuffle data cleanup for ungracefully terminated
Executors is not a bad idea, but is a (smallish) feature onto itself, as the
Worker does not currently know where a particular Executor is storing its data.
> Standalone Worker cleanup should not clean up running executors
> ---------------------------------------------------------------
>
> Key: SPARK-1860
> URL: https://issues.apache.org/jira/browse/SPARK-1860
> Project: Spark
> Issue Type: Bug
> Components: Deploy
> Affects Versions: 1.0.0
> Reporter: Aaron Davidson
> Priority: Blocker
>
> The default values of the standalone worker cleanup code cleanup all
> application data every 7 days. This includes jars that were added to any
> executors that happen to be running for longer than 7 days, hitting streaming
> jobs especially hard.
> Executor's log/data folders should not be cleaned up if they're still
> running. Until then, this behavior should not be enabled by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
