如何調整spark執行器編號，內核和執行程序內存？

Question

你從哪里開始調整上面提到的參數。 我們從執行程序內存開始並獲取執行程序的數量，或者從核心開始並獲取執行程序編號。 我按照鏈接 。 但是有一個高層次的想法，但仍然不確定如何或從哪里開始並得出最終結論。

Answer 1

以下答案涵蓋了標題中提到的3個主要方面 - 執行程序數，執行程序內存和核心數。 可能還有其他參數，如驅動程序內存和其他一些我在本答案中沒有解決的問題，但是想在不久的將來添加。

案例1硬件 - 6個節點，每個節點16個內核，64 GB RAM

每個執行程序都是JVM實例。 因此，我們可以在單個節點中擁有多個執行程序

OS和Hadoop守護程序需要前1個核心和1 GB，因此每個節點可以使用15個核心，63 GB RAM

從如何選擇核心數開始 ：

Number of cores = Concurrent tasks as executor can run 

So we might think, more concurrent tasks for each executor will give better performance. But research shows that
any application with more than 5 concurrent tasks, would lead to bad show. So stick this to 5.

This number came from the ability of executor and not from how many cores a system has. So the number 5 stays same
even if you have double(32) cores in the CPU.

執行人數：

Coming back to next step, with 5 as cores per executor, and 15 as total available cores in one Node(CPU) - we come to 
3 executors per node.

So with 6 nodes, and 3 executors per node - we get 18 executors. Out of 18 we need 1 executor (java process) for AM in YARN we get 17 executors

This 17 is the number we give to spark using --num-executors while running from spark-submit shell command

每個遺囑執行人的記憶：

From above step, we have 3 executors  per node. And available RAM is 63 GB

So memory for each executor is 63/3 = 21GB. 

However small overhead memory is also needed to determine the full memory request to YARN for each executor.
Formula for that over head is max(384, .07 * spark.executor.memory)

Calculating that overhead - .07 * 21 (Here 21 is calculated as above 63/3)
                            = 1.47

Since 1.47 GB > 384 MB, the over head is 1.47.
Take the above from each 21 above => 21 - 1.47 ~ 19 GB

So executor memory - 19 GB

最終號碼 - 執行者 - 17，核心5，執行者內存 - 19 GB

---

案例2硬件：相同的6節點，32核，64 GB

5對於良好的並發性是相同的

每個節點的執行者數量= 32 / 5~6

因此總執行器= 6 * 6節點= 36.然后，對於AM = 35，最終數字為36-1

執行程序內存為：每個節點有6個執行程序。 63 / 6~10。 頭頂是.07 * 10 = 700 MB。 所以四舍五入為1GB，我們得到10-1 = 9 GB

最終號碼 - 執行者 - 35，核心5，執行者內存 - 9 GB

---

案例3

上述場景始於接受固定的核心數量並轉移到執行器和內存的數量。

現在對於第一種情況，如果我們認為我們不需要19 GB，只有10 GB就足夠了，那么下面是數字：

每個節點的核心5＃執行者= 3

在這個階段，根據我們的第一次計算，這將導致21，然后是19。 但是因為我們認為10是好的（假設開銷很小），那么我們不能將每個節點的執行者＃切換到6（如63/10）。 當我們只有16個核心時，每個節點有5個執行器，5個核心每個節點有30個核心。 因此，我們還需要更改每個執行程序的核心數。

所以再次計算，

幻數5變為3（任何小於或等於5的數字）。 因此，有3個內核和15個可用內核 - 每個節點有5個執行器。 所以（5 * 6 -1）= 29位遺囑執行人

因此內存為63 / 5~12。頭部為12 * .07 = .84因此執行程序內存為12 - 1 GB = 11 GB

最終數字是29個執行器，3個核心，執行程序內存為11 GB

---

動態分配：

注意：如果啟用了動態分配，則執行程序數量的上限。 因此，如果需要，火花應用程序可以消耗掉所有資源。 因此，在您正在運行其他應用程序並且還需要核心來運行任務的群集中，請確保您在群集級別執行此操作。 我的意思是您可以根據用戶訪問權限為YARN分配特定數量的核心。 因此，您可以創建spark_user，然后為該用戶提供核心（最小/最大）。 這些限制用於在YARN上運行的spark和其他應用程序之間共享。

spark.dynamicAllocation.enabled - 當它設置為true時 - 我們不需要提及執行程序。 原因如下：

我們在spark-submit時提供的靜態參數號用於整個作業持續時間。 然而，如果動態分配出現，那么會有不同的階段

什么開始：

要開始的執行者的初始數量（ spark.dynamicAllocation.initialExecutors ）

多少 ：

然后根據負載（待處理的任務）請求多少。 這最終將是我們以靜態方式提供spark-submit的數字。 因此，一旦設置了初始執行程序編號，我們將轉到min（ spark.dynamicAllocation.minExecutors ）和max（ spark.dynamicAllocation.maxExecutors ）數字。

什么時候問或給：

我們何時請求新的執行程序（ spark.dynamicAllocation.schedulerBacklogTimeout ） - 在這么長的時間內有待處理的任務。 所以要求。 每輪請求的執行者數量與上一輪相比呈指數增長。 例如，一個應用程序將在第一輪中添加1個執行程序，然后在后續輪次中添加執行程序中的2,4,8等。 在特定點上，上面的最大值出現了

我們什么時候放棄執行者（ spark.dynamicAllocation.executorIdleTimeout ） -

如果我錯過任何事情，請糾正我。 以上是基於我分享的博客和一些在線資源的理解。 謝謝。

參考文獻：

• http://site.clairvoyantsoft.com/understanding-resource-allocation-configurations-spark-application/
• http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation
• http://spark.apache.org/docs/latest/job-scheduling.html#resource-allocation-policy

Answer 2

此外，它取決於您的用例，一個重要的配置參數是：

spark.memory.fraction （用於執行和存儲的（堆空間 - 300MB）的分數）來自http://spark.apache.org/docs/latest/configuration.html#memory-management 。

如果您不使用緩存/持久性，請將其設置為0.1，這樣您就擁有了程序的所有內存。

如果使用緩存/持久性，則可以檢查以下內存：

sc.getExecutorMemoryStatus.map(a => (a._2._1 - a._2._2)/(1024.0*1024*1024)).sum

您是從HDFS還是從HTTP讀取數據？

同樣，調整取決於您的用例。