标签：executors executor num gc memory 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。

标签：executors,executor,num,gc,memory,cores,分配资源
来源： https://www.cnblogs.com/chong-zuo3322/p/16140035.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。