某神州優秀員工：一閃，領導說要給我漲米。

一閃：。。。。（著急的團團轉）

---

老運維：Oi，兩個吊毛，看看你們的hadoop集群，健康度30分，怎么還在抽思謀克？
①Flink流作業（常駐任務，占用20個Container）
②Hive夜間ETL批處理（每日1次，需50個Container）
③Spark ML模型訓練（每周執行，需80個Container）
近期頻繁出現：
①Hive ETL超時3小時以上
②Spark任務因ExitCode: 143被YARN強制終止
③Flink作業反壓報警持續10分鐘/次
老員工：好像資源有點緊張啊。
一閃：豈止是有點緊張（收拾東西），我媽喊我回家吃飯了。
老員工：給你個表現的機會，快處理下。
一閃：肯定是資源調度器的問題，之前用的公平調度（Fair Scheduler）壓根沒配任務權重和任務最小資源保證，出問題不是遲早得事情嗎。Flink任務是常駐任務，持續占用20個Container，其他的批處理任務重疊得時候集群資源肯定不足了。spark報錯143就是外部關閉，說明是yarn殺任務釋放資源了。說到頭這不是你們運維應該優化嗎，怎么又找我們了。
老運維：快點處理下，等會請你們抽思謀克，紅色軟殼的。

（臥槽，是軟華子）
一閃：主要是想解決問題，和思謀克沒啥關系。
先看看幾個關鍵的參數：
yarn.nodemanager.resource.cpu-vcores = -1;
yarn.nodemanager.resource.detect-hardware-capabilities = false;
一閃：快快快，第二個參數改成true。
這時候就會有小朋友問了，啊，第一個參數我知道，網上說都要改成物理機的實際核心數，你怎么要改下面那個啊？
莫慌，莫慌，hadoop.apache.org啟動（做什么事情都要先看官網，某度某AI都是耍流氓）
具體鏈接：https://hadoop.apache.org/docs/r3.3.4/hadoop-yarn/hadoop-yarn-common/yarn-default.xml

所以可以看出來，如果你要改上面那個，那么還需要去確認真實的核心數，如果你有亂七八糟幾十臺機器....好像是有點恐怖的....所以我們直接把yarn.nodemanager.resource.detect-hardware-capabilities改成true。這樣yarn會以機器實際的核心數為準，而且你只要把配置文件分發到所有節點上就完整了集群的配置修改！

這里又要有小朋友問了，啊，那我改之前假如我的機器核心數是4核和16核，分別會有什么癥狀呢？

如果改參數之前核數只有4個，那么就是一個牛馬要干兩個牛馬的活，別看了說的就是你.....也就是CPU上下文切換頻率會和你的血壓一樣飆升....總而言之就是因為資源不足會導致很多問題。
如果改參數之前核數有16個，那么就是會有一半的資源在摸魚，機器數量越多浪費的資源也就越多，你也不想你摸魚的事情被老板知道吧...

說到這里有些小朋友就興致勃勃的去改配置了，但是，慢！
有些反應慢的小朋友就會問了，啊，那我的是k8s和docker，這也能用自檢查參數來獲取核數嗎？
老運維：搶答，在容器化部署的場景下，一定要關掉自檢查并顯示指定vcores，不然多半會超賣，然后歇菜。
一閃：吊毛搞了半天你知道啊，那你還讓我們看。
老運維：我只是讓你們幫忙分析下問題...又沒說不會優化。。
一閃：快請我一根思謀克。
老運維拿出了一盒扁了的硬云，說盒子已經被他捏軟了......