spark调优-如何合理的分配资源（executor-memory,num-executors,executor-cores）

executor-memory

在集群资源允许的情况下，且不oom的情况下，通常越多越好，同时要在webui观察gc时长，达到平衡值(过多的内存会导致单次gc所需时间过长，过少的内存会导致频繁gc)，个人建议上限为单个containers最大值的75%。

 

num-executors,executor-cores

num-executors和executor-cores，由于执行任务的并发数=num-executors * executor-cores 。所以这一点经常会思考是100*1好，还是50*2比较好？

1.假设shuffer压力不大

（1）在数据分布均匀，executor-memory=8G，100*1是比50*2的理论上是要好些的，因为这样单个任务所拥有的内存会更充足，gc的次数会更少。

（2）在数据分布不均匀的情况下，可设置executor-memory=16G，50*2理论上是比100*1效果要好些的，因为如果设置为100*1，数据量小的任务会很快执行完，造成executor空闲。资源浪费。且在数据不均匀的情况下，executor-memory要适当提高，以免oom。

2.若shuffer有一定压力

（1）shuffer的本质是在网络磁盘IO，假设每个executor都分布在不同的节点，那么过多的executor-num会造成网络之间的IO过大，shuffer read可能造成timeout。所以这个时候理论上是设置较小的executor-num,较多的executor-cores，和较大的executor-memory是比较合理。以上文为例： executor-memory=32G num-executors=25 executor-cores =4

3.若任务主要是sc.textFile().map().saveAsTextFile

那么其瓶颈主要是在读取hdfs文件，以及业务代码运行效率上。在单个节点给予过多的executor-cores，可能造成节点和hdfs的IO打满。那么这个时候应该适当降低executor-cores，增加executor-num。