如前文，为了彻底解决Yarn提交任务之后停留在ACCEPTED的问题，我们对Yarn的资源分配做了多组实验，过程及结果如下。
调度方式：FairScheduler
节点配置信息：
Spark on Yarn实验：
client模式和cluster模式差距不大，统一用client运行一个资源消耗比较大的连表Spark SQL查询并输出。
- 第一次实验
Driver: 1核2g
executor：1核2g
executor/container数量：未指定
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
实验结果：
成功运行
Driver：1核3g
excutor：1核3g
executor数量：6个
- 简单解释下，3g是因为Yarn会额外把分配的内存，加上max(384,10%已分配的内存)，规整向上1024MB，即为3g。
- 第二次实验：
Driver: 1核2g
executor：1核2g
executor/container数量：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
实验结果：
成功运行：
Driver：1核3G
Executor：1核3G
Executor个数：2个
实验结论1：在Fair模式下，不指定Executor数量，则会尽量多的配置，结果不固定；指定数量的话，按照指定的来配置。
- 第三次实验：
Driver: 1核4g
executor：2核4g
executor/container数量：未指定
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
实验结果：
成功运行：
Driver：1核5G
Executor：2核5G
Executor个数：2个
- 第四次实验：
第四次实验我们过度指定Executor数量，看会不会陷入ACCEPTED：
Driver: 1核4g
executor：2核4g
executor/container数量：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
实验结果：
成功运行
Driver：1核5G
Executor：2核5G
Executor个数：2个
实验结论2：在Fair模式下，过度指定Executor数量会被忽视。
- 第五次实验：
第五次试验我们对资源需求过度要求，再次看看情况
Driver: 2核4g
executor：3核8g
executor/container数量：未指定
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
实验结果：
在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'.
这个主要是因为我们设置了单个应用最大申请的资源为3核6g，超过的拒绝接受，发token。
- 第六次实验：
第六次试验我们仍然对资源需求过度要求，但不超过限制，再次看看情况
Driver: 2核4g
executor：3核5g
executor/container数量：未指定
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
实验结果：
Driver：1核5g(不知道为什么CPU核被削减了)
Exexutor：3核6g
executor/container数量：2个
- 第七次实验
第七次试验我们满载
Driver: 3核5g
executor：3核5g
executor/container数量：未指定
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
实验结果：
运行成功
Driver：1核5g
Exexutor：3核6g
executor/container数量：未指定
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
实验结论3：在Fair模式下，Driver的cpu cores会被设为1个，内存不会增加10%
综上来看，对每个任务进行资源限制，是非常重要的！！
接下来我们测试多任务在Fair Scheduler的调度情况。
我们统一设置为一个队列。
- 第八次实验
任务1：
Driver: 1核2g
executor：2核5g
executor/container数量：未指定
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
任务2资源申请同任务1
实验结果：
任务1运行成功，任务2ACCEPTED。
任务1运行结束，任务2RUNNING。
- 第九次实验
任务1：
Driver: 1核2g
executor：1核2g
executor/container数量：未指定
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
任务2资源申请同任务1
实验结果：
任务1运行成功，分配了4个Executor
任务2Accepted了..
在任务1运行结束后，任务2长时间ACCEPTED了。。。
原来是同事把主机名给改了，看了日志才知道，Yarn不认识，一直在发请求，重新实验。
同时RUNNING起来了。
经验教训：多读日志！
