該文章寫于spark1.6.2版本。
由于Fine mode對短任務(wù)性能影響過大，所以采用的是Coarse mode方式進(jìn)行調(diào)度。

主要的一些問題：

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的浪費(fèi)。
   具體可參考http://www.itdecent.cn/p/27762a1f9b7b

3. 每個executor使用的cpu數(shù)量不可控

   例如某個application申請<5 cores,10G RAM>，如果每個slave只有4 cores,就會造成出現(xiàn)的兩個executor,一個是<4 cores,10G RAM>，另一個是<1 core, 10G RAM>。
   因?yàn)橐粋€executor運(yùn)行了過多的task，在內(nèi)存不足的情況下就非常容易造成OOM,長時間GC等問題。
   具體可參考http://www.itdecent.cn/p/27762a1f9b7b

4. blockmgr沒有自動刪除
   大量占用磁盤空間

這些問題都在2.0中得到了解決，但是2.0的改動較大，涉及到大量程序的修改，所以就將如下的改進(jìn)和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

修復(fù)后的集群濟(jì)源利用率

修改后的集群負(fù)載情況(ganglia):

這里寫圖片描述

修改后的集群負(fù)載情況(ganglia):

這里寫圖片描述