[ https://issues.apache.org/jira/browse/SPARK-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432165#comment-16432165 ]
Attila Zsolt Piros edited comment on SPARK-16630 at 4/10/18 12:15 PM: ---------------------------------------------------------------------- I have question regarding limiting the number of blacklisted nodes according to the cluster size. With this change there will be two sources of nodes to be backlisted: - one list is coming from the scheduler (existing node level backlisting) - the other is computed here close to the YARN allocator (stored along with the expiry times) I think it makes sense to have the limit for the complete list (union) of blacklisted nodes, am I right? If this limit is for the complete list then regarding the subset I think the newly blacklisted nodes are more up-to-date to be used then the earlier backlisted ones. So I would pass the expiry times from the scheduler to the YARN allocator to make the subset of backlisted nodes to be communicated to YARN. What is your opinion? was (Author: attilapiros): I have question regarding limiting the number of blacklisted nodes according to the cluster size. With this change there will be two sources of nodes to be backlisted: - one list is coming from the scheduler (existing node level backlisting) - the other is computed here close to the YARN (stored along with the expiry times) I think it makes sense to have the limit for the complete list (union) of blacklisted nodes, am I right? If this limit is for the complete list then regarding the subset I think the newly blacklisted nodes are more up-to-date to be used then the earlier backlisted ones. So I would pass the expiry times from the scheduler to the YARN allocator to make the subset of backlisted nodes to be communicated to YARN. What is your opinion? > Blacklist a node if executors won't launch on it. > ------------------------------------------------- > > Key: SPARK-16630 > URL: https://issues.apache.org/jira/browse/SPARK-16630 > Project: Spark > Issue Type: Improvement > Components: YARN > Affects Versions: 1.6.2 > Reporter: Thomas Graves > Priority: Major > > On YARN, its possible that a node is messed or misconfigured such that a > container won't launch on it. For instance if the Spark external shuffle > handler didn't get loaded on it , maybe its just some other hardware issue or > hadoop configuration issue. > It would be nice we could recognize this happening and stop trying to launch > executors on it since that could end up causing us to hit our max number of > executor failures and then kill the job. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org