吐槽
最近“閒”來無事，通過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(後實際調成了96G)，這樣就能將所有的CPU都利用起來了。
測試結果
yarn.nodemanager.resource.memory-mb爲8G時：
Time taken: 3794.17 seconds
Total MapReduce CPU Time Spent: 3 days 10 hours 43 minutes 22 seconds 640 msec
yarn.nodemanager.resource.memory-mb爲16G時：
Time taken: 2077.138 seconds
Total MapReduce CPU Time Spent: 3 days 12 hours 55 minutes 43 seconds 210 msec
可以看到確實快了很多很多。(ps:兩次跑的任務所用的數據不一樣，以免緩存導致第二次跑相同的任務會速度比第一次快，但兩次任務所用的數據量差不多，都在650G左右)
其它
查看VCores SQL
|
1
|
SELECT
allocated_vcores_cumulative,
available_vcores where
category=YARN_POOL
and serviceName=“yarn”
and queueName=root
|
查看分配給Yarn的內存 SQL
|
1
|
SELECT
allocated_memory_mb_cumulative,
available_memory_mb where
category=YARN_POOL
and serviceName=“yarn”
and queueName=root
|
當然最簡單的查看方式就是在CM的“動態資源池”頁面看。