**某神州优秀员工：**一闪，领导说要给我涨米。
一闪：。。。。（着急的团团转）
老运维： 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，不然多半会超卖，然后歇菜。
一闪： 吊毛搞了半天你知道啊，那你还让我们看。
老运维： 我只是让你们帮忙分析下问题...又没说不会优化。。
一闪： 快请我一根思谋克。
老运维拿出了一盒扁了的硬云，说盒子已经被他捏软了......
