如前文，為了徹底解決Yarn提交任務(wù)之后停留在ACCEPTED的問題败徊，我們對Yarn的資源分配做了多組實驗帚呼，過程及結(jié)果如下。
調(diào)度方式：FairScheduler
節(jié)點配置信息：
Spark on Yarn實驗：
client模式和cluster模式差距不大皱蹦，統(tǒng)一用client運行一個資源消耗比較大的連表Spark SQL查詢并輸出煤杀。
- 第一次實驗
Driver: 1核2g
executor：1核2g
executor/container數(shù)量：未指定
spark-submit --master yarn --conf spark.yarn.am.memory=2g --conf spark.yarn.am.cores=1 --conf spark.executor.cores=1 --executor-memory 2g ./src/main/pybin/ttemp.py
實驗結(jié)果：
成功運行
Driver：1核3g
excutor：1核3g
executor數(shù)量：6個
- 簡單解釋下，3g是因為Yarn會額外把分配的內(nèi)存沪哺，加上max(384,10%已分配的內(nèi)存)沈自，規(guī)整向上1024MB，即為3g辜妓。
- 第二次實驗：
Driver: 1核2g
executor：1核2g
executor/container數(shù)量：2
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=2g --conf spark.yarn.am.cores=1 --conf spark.executor.cores=1 --executor-memory 2g --num-executors 2 ./src/main/pybin/ttemp.py
實驗結(jié)果：
成功運行：
Driver：1核3G
Executor：1核3G
Executor個數(shù)：2個
實驗結(jié)論1：在Fair模式下枯途，不指定Executor數(shù)量，則會盡量多的配置籍滴，結(jié)果不固定柔袁；指定數(shù)量的話，按照指定的來配置异逐。
- 第三次實驗：
Driver: 1核4g
executor：2核4g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=4g --conf spark.yarn.am.cores=1 --conf spark.executor.cores=2 --executor-memory 4g ./src/main/pybin/ttemp.py
實驗結(jié)果：
成功運行：
Driver：1核5G
Executor：2核5G
Executor個數(shù)：2個
- 第四次實驗：
第四次實驗我們過度指定Executor數(shù)量，看會不會陷入ACCEPTED：
Driver: 1核4g
executor：2核4g
executor/container數(shù)量：5
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=4g --conf spark.yarn.am.cores=1 --conf spark.executor.cores=2 --executor-memory 4g --num-executors 5 ./src/main/pybin/ttemp.py
實驗結(jié)果：
成功運行
Driver：1核5G
Executor：2核5G
Executor個數(shù)：2個
實驗結(jié)論2：在Fair模式下插掂，過度指定Executor數(shù)量會被忽視灰瞻。
- 第五次實驗：
第五次試驗我們對資源需求過度要求，再次看看情況
Driver: 2核4g
executor：3核8g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=4g --conf spark.yarn.am.cores=2 --conf spark.executor.cores=3 --executor-memory 8g ./src/main/pybin/ttemp.py
實驗結(jié)果：
在Spark端就掛掉了
java.lang.IllegalArgumentException: Required executor memory (8192), overhead (819 MB), and PySpark memory (0 MB) is above the max threshold (6144 MB) of this cluster! Please check the values of 'yarn.scheduler.maximum-allocation-mb' and/or 'yarn.nodemanager.resource.memory-mb'.
這個主要是因為我們設(shè)置了單個應(yīng)用最大申請的資源為3核6g辅甥，超過的拒絕接受酝润，發(fā)token。
- 第六次實驗：
第六次試驗我們?nèi)匀粚Y源需求過度要求璃弄，但不超過限制要销，再次看看情況
Driver: 2核4g
executor：3核5g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=4g --conf spark.yarn.am.cores=2 --conf spark.executor.cores=3 --executor-memory 5g ./src/main/pybin/ttemp.py
實驗結(jié)果：
Driver：1核5g(不知道為什么CPU核被削減了)
Exexutor：3核6g
executor/container數(shù)量：2個
- 第七次實驗
第七次試驗我們滿載
Driver: 3核5g
executor：3核5g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=4g --conf spark.yarn.am.cores=2 --conf spark.executor.cores=3 --executor-memory 5g ./src/main/pybin/ttemp.py
實驗結(jié)果：
運行成功
Driver：1核5g
Exexutor：3核6g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=5g --conf spark.yarn.am.cores=3 --conf spark.executor.cores=3 --executor-memory 5g ./src/main/pybin/ttemp.py
實驗結(jié)論3：在Fair模式下，Driver的cpu cores會被設(shè)為1個夏块，內(nèi)存不會增加10%
綜上來看疏咐，對每個任務(wù)進(jìn)行資源限制，是非常重要的Ｆ旯浑塞！
接下來我們測試多任務(wù)在Fair Scheduler的調(diào)度情況。
我們統(tǒng)一設(shè)置為一個隊列政己。
- 第八次實驗
任務(wù)1：
Driver: 1核2g
executor：2核5g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=2g --conf spark.executor.cores=2 --executor-memory 5g ./src/main/pybin/ttemp.py
任務(wù)2資源申請同任務(wù)1
實驗結(jié)果：
任務(wù)1運行成功酌壕，任務(wù)2ACCEPTED。
任務(wù)1運行結(jié)束，任務(wù)2RUNNING卵牍。
- 第九次實驗
任務(wù)1：
Driver: 1核2g
executor：1核2g
executor/container數(shù)量：未指定
spark-submit --master yarn --deploy-mode client --conf spark.yarn.am.memory=2g --conf spark.executor.cores=1 --executor-memory 2g ./src/main/pybin/ttemp.py
任務(wù)2資源申請同任務(wù)1
實驗結(jié)果：
任務(wù)1運行成功果港，分配了4個Executor
任務(wù)2Accepted了..
在任務(wù)1運行結(jié)束后，任務(wù)2長時間ACCEPTED了糊昙。辛掠。。
原來是同事把主機(jī)名給改了溅蛉，看了日志才知道公浪，Yarn不認(rèn)識，一直在發(fā)請求船侧，重新實驗欠气。
同時RUNNING起來了。
經(jīng)驗教訓(xùn)：多讀日志镜撩！
