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() { } });