Spark-troubleshooting-YARN队列资源不足导致app失效

troubleshooting YARN队列资源不足导致的application直接失败


现象：


如果说，你是基于yarn来提交spark。比如yarn-cluster或者yarn-client。
你可以指定提交到某个yarn队列上的。每个队列都是可以有自己的资源的。


跟大家说一个生产环境中的，给spark用的yarn资源队列的情况：500G内存，200个cpu core。


比如说，某个spark application，在spark-submit里面你自己配了，executor，80个；每个executor，
4G内存；每个executor，2个cpu core。你的spark作业每次运行，大概要消耗掉320G内存，
以及160个cpu core。


乍看起来，咱们的队列资源，是足够的，500G内存，200个cpu core。


首先，第一点，你的spark作业实际运行起来以后，耗费掉的资源量，可能是比你在spark-submit里面
配置的，以及你预期的，是要大一些的。400G内存，190个cpu core。


那么这个时候，的确，咱们的队列资源还是有一些剩余的。但是问题是，如果你同时又提交了一个
spark作业上去，一模一样的。那就可能会出问题。


第二个spark作业，又要申请320G内存+160个cpu core。结果，发现队列资源不足。。。。


此时，可能会出现两种情况：（备注，具体出现哪种情况，跟你的YARN、Hadoop的版本，
你们公司的一些运维参数，以及配置、硬件、资源肯能都有关系）


1、YARN，发现资源不足时，你的spark作业，并没有等待在那里，等待资源的分配，
而是直接打印一行fail的log，直接就fail掉了。
2、YARN，发现资源不足，你的spark作业，就等待在那里。一直等待之前的spark作业执行完，
等待有资源分配给自己来执行。




采用如下方案：


1、在你的J2EE（我们这个项目里面，spark作业的运行，之前说过了，J2EE平台触发的，
执行spark-submit脚本），限制，同时只能提交一个spark作业到yarn上去执行，
确保一个spark作业的资源肯定是有的。


2、你应该采用一些简单的调度区分的方式，比如说，你有的spark作业可能是要长时间运行的，
比如运行30分钟；有的spark作业，可能是短时间运行的，可能就运行2分钟。此时，
都提交到一个队列上去，肯定不合适。很可能出现30分钟的作业卡住后面一大堆2分钟的作业。
分队列，可以申请（跟你们的YARN、Hadoop运维的同学申请）。你自己给自己搞两个调度队列。
每个队列的根据你要执行的作业的情况来设置。在你的J2EE程序里面，要判断，如果是长时间运行的作业，
就干脆都提交到某一个固定的队列里面去把；如果是短时间运行的作业，就统一提交到另外一个队列里面去。
这样，避免了长时间运行的作业，阻塞了短时间运行的作业。


3、你的队列里面，无论何时，只会有一个作业在里面运行。那么此时，
就应该用我们之前讲过的性能调优的手段，去将每个队列能承载的最大的资源，
分配给你的每一个spark作业，比如80个executor；6G的内存；3个cpu core。
尽量让你的spark作业每一次运行，都达到最满的资源使用率，最快的速度，最好的性能；并行度，
240个cpu core，720个task。


4、在J2EE中，通过线程池的方式（一个线程池对应一个资源队列），来实现上述我们说的方案。
最后和大家说一下，在你的J2EE平台里面，怎么控制你的资源队列同时只能跑一个作业！？？？可以用线程池
来控制，创建线程池容量只有1的这么一个线程池，每一次提交一个作业，就会到这个线程池里面去，
它空闲的时候就会有一个作业去跑，后面如果再有一个作业要跑的话，也扔到这个线程池里面，当然
它的容量只有1，后面的这些作业线程要去执行，要去启动spark作业的线程，它就会在那里排队，这个
线程池自动的给你实现了这个排队机制，不同的作业要放到不同的资源队列里面去运行，那就很简单嘛！
不同的作业放到不同的线程池！你可以搞多个线程池，每个线程池就对应着一个资源队列！


ExecutorService threadPool = Executors.newFixedThreadPool(1);


threadPool.submit(new Runnable() {

@Override
public void run() {


}

});