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。