CDH叢集調優：記憶體、Vcores和DRF

吐槽

最近“閒”來無事，透過CM把vcores使用情況調出來看了一眼，發現不論叢集中有多少個任務在跑，已分配的VCores始終不會超過120。而叢集的可用Vcores是360（15臺機器×24虛擬核）。這就相當於CPU資源只用到了1/3，作為一個半強迫症患者絕對不能容忍這樣的事情發生。

分析的過程不表，其實很簡單就是幾個引數的問題。本以為CM能智慧的將這些東西配好，現在看來好像不行。以下記錄結論。

DRF和相關引數

DRF: Dominant Resource Fairness，根據CPU和記憶體公平排程資源。CDH動態資源池預設採用的DRF計劃策略。簡單的理解就是記憶體不夠的時候，多餘的CPU就不會分配任務了，就讓他空著；CPU不夠的時候，多出來的記憶體也不會再啟動任務了。

理解這個計劃策略後，再檢視Yarn啟動任務時資源相關的引數，發現有以下幾個引數可能會產生影響：

• mapreduce.map.memory.mb ，map任務記憶體，cdh預設1G
• mapreduce.map.cpu.vcores ，map任務虛擬CPU核數，cdh預設1
• mapreduce.reduce.memory.mb ，reduce任務記憶體，cdh預設1G
• mapreduce.reduce.cpu.vcores ，reduce任務虛擬CPU核數，cdh預設1
• yarn.nodemanager.resource.memory-mb ，容器記憶體，cdh預設8G
• yarn.nodemanager.resource.cpu-vcores ，容器虛擬CPU核數，cdh預設8，但CM會自動檢測核心數並修改，我這裡被自動改成了24。

可以看到預設配置下，CPU核數和記憶體是1：1G的比例來啟動任務的。

接著檢視了下分配給Yarn的記憶體，果然是8×15=120G，所以可用記憶體比可用vcores（360個）比起來就小太多了，導致按照1：1G的比例下最多隻能使用120個vcores。

。

測試

為了證實我的猜想，將 yarn.nodemanager.resource.memory-mb 調成了16G（我們記憶體128G，管夠）。重啟yarn後，再次啟動MR，於是有了下圖：

可以看到引數調整前，Yarn可用記憶體為120G，調整後變成了240G；vcores由調整前的120變成了240。至此，證明猜想正確。

所以對於這個叢集來說，由於記憶體為128G，核心為24個，所以完全可以將 yarn.nodemanager.resource.memory-mb 引數調成24G，這樣就能將所有的CPU都利用起來了。

測試結果

yarn.nodemanager.resource.memory-mb 為8G時：

yarn.nodemanager.resource.memory-mb 為16G時：

可以看到確實快了很多很多。(ps:兩次跑的任務所用的資料不一樣，以免快取導致第二次跑相同的任務會速度比第一次快，但兩次任務所用的資料量差不多，都在650G左右)

其它

檢視VCores SQL

SELECT allocated_vcores_cumulative, available_vcores where category=YARN_POOL and serviceName="yarn" and queueName=root

檢視分配給Yarn的記憶體 SQL

SELECT allocated_memory_mb_cumulative, available_memory_mb where category=YARN_POOL and serviceName="yarn" and queueName=root

當然最簡單的檢視方式就是在CM的“動態資源池”頁面看。

轉: http://blog.selfup.cn/1631.html?utm_source=tuicool&utm_medium=referral