Spark on mesos的坑以及解决办法

该文章写于spark1.6.2版本。
由于Fine mode对短任务性能影响过大，所以采用的是Coarse mode方式进行调度。

主要的一些问题：

1. 1.6版本开始dynamic allocation无法使用

   例如spark-shell之类的程序，空闲时期资源长期占用却无法释放，造成资源利用率低下。

2. 单个slave上无法启动多个executor

   每个mesos slave上一个application只能启动一个executor。带来的问题是，如果你的slave是<20 cores,100G RAM>，一个需求<20 cores，10G RAM>的application就会将其资源用光，造成90G RAM的浪费。
   具体可参考http://blog.csdn.net/lsshlsw/article/details/51820420

3. 每个executor使用的cpu数量不可控

   例如某个application申请<5 cores,10G RAM>，如果每个slave只有4 cores,就会造成出现的两个executor,一个是<4 cores,10G RAM>，另一个是<1 core, 10G RAM>。
   因为一个executor运行了过多的task，在内存不足的情况下就非常容易造成OOM,长时间GC等问题。
   具体可参考http://blog.csdn.net/lsshlsw/article/details/51820420

4. blockmgr没有自动删除
   大量占用磁盘空间

这些问题都在2.0中得到了解决，但是2.0的改动较大，涉及到大量程序的修改，因此可以将如下的改进和bugfix都合到了1.6.2上，重新build一个版本，问题解决。

已有的解决方案：

• [SPARK-12330][MESOS] Fix mesos coarse mode cleanup
• [SPARK-13002][MESOS] Send initial request of executors for dyn allocation
• [SPARK-5095][MESOS] Support launching multiple mesos executors in coarse grained mesos mode.
• [SPARK-12583][MESOS] Mesos shuffle service: Don’t delete shuffle files before application has stopped
• [SPARK-13001][CORE][MESOS] Prevent getting offers when reached max cores

修复后的集群济源利用率

修改后的集群负载情况(ganglia):

修改后的集群负载情况(ganglia):