吐槽

最近“閑”來無事，通過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時：

Time taken: 3794.17 secondsTotal MapReduce CPU Time Spent: 3 days 10 hours 43 minutes 22 seconds 640 msec

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

Time taken: 2077.138 secondsTotal MapReduce CPU Time Spent: 3 days 12 hours 55 minutes 43 seconds 210 msec

可以看到確實快了很多很多。(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

總結

以上是生活随笔為你收集整理的CDH集群调优：内存、Vcores和DRF的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。