节点配置调优
- 操作场景
合理配置大数据集群的调度器后，还可通过调节每个节点的可用内存、CPU资源及本地磁盘的配置进行性能调优。
具体包括以下配置项：可用内存、CPU虚拟核数、物理CPU使用百分比、内存和CPU资源的协调、本地磁盘。 - 操作步骤
可用内存
除了分配给操作系统、其他服务的内存外，剩余的资源应尽量分配给YARN。通过如下配置参数进行调整。
例如，如果一个container默认使用512M，则内存使用的计算公式为：512M*container数。
默认情况下，Map或Reduce container会使用1个虚拟CPU内核和1024MB内存，ApplicationMaster使用1536MB内存。参数 描述 默认值 yarn.nodemanager.resource.memory-mb 设置可分配给容器的物理内存数量。单位：MB，取值范围大于0。
建议配置成节点物理内存总量的80%。若该节点有其他业务的常驻进程，请降低此参数值给该进程预留足够运行资源。10240 CPU虚拟核数
建议将此配置设定在逻辑核数的1.5～2倍之间。如果上层计算应用对CPU的计算能力要求不高，可以配置为2倍的逻辑CPU。参数 描述 默认值 yarn.nodemanager.resource.cpu-vcores 目前推荐将该值设置为逻辑CPU核数的1.5～2倍之间 10 物理CPU使用百分比
建议预留适量的CPU给操作系统和其他进程（数据库、HBase等）外，剩余的CPU核都分配给YARN。可以通过如下配置参数进行调整。参数 描述 默认值 yarn.nodemanager.resource.percentage-physical-cpu-limit 表示该节点上YARN可使用的物理CPU百分比。默认是80，即不进行CPU控制，YARN可以使用节点全部CPU。该参数只支持查看，可通过调整YARN的RES_CPUSET_PERCENTAGE参数来修改本参数值。注意，目前推荐将该值设为可供YARN集群使用的CPU百分数。 80 本地磁盘
由于本地磁盘会提供给MapReduce写job执行的中间结果，数据量大。因此配置的原则是磁盘尽量多，且磁盘空间尽量大，单个达到百GB以上规模最好。简单的做法是配置和DataNode相同的磁盘，只在最下一级目录上不同即可。参数 描述 默认值 yarn.nodemanager.log-dirs 日志存放地址 {{nm_log_dirs}} yarn.nodemanager.local-dirs 本地化后的文件的存储位置 {{nm_local_dirs}}
任务优先级
- 集群的资源竞争场景如下：
提交两个低优先级的应用Job 1和Job 2。
正在运行中的Job 1和Job 2有部分task处于running状态，但由于集群或队列资源容量有限，仍有部分task未得到资源而处于pending状态。
提交一个较高优先级的应用Job 3，此时会出现如下资源分配情况：当Job 1和Job 2中running状态的task运行结束并释放资源后，Job 3中处于pending状态的task将优先得到这部分新释放的资源。
Job 3完成后，资源释放给Job 1、Job 2继续执行。
用户可以在YARN中配置任务的优先级。任务优先级是通过ResourceManager的调度器实现的。 - 操作步骤
设置参数“mapreduce.job.priority”，使用命令行接口或API接口设置任务优先级。
命令行：提交任务时，添加“-Dmapreduce.job.priority=”参数。
可以设置为：VERY_HIGH、HIGH、NORMAL、LOW、VERY_LOW。
RM处于Standby状态，无法自动恢复Active状态，该如何处理
检查支持自动恢复的必选配置项是否配置正确。
参数 描述 yarn.resourcemanager.ha.enabled 需要配置为true yarn.resourcemanager.ha.automatic-failover.enabled 需要配置为true 修改为上述配置后，问题还未解决，您可以通过以下方式排查问题：
- 检查ZooKeeper服务是否正常。
- 检查ZooKeeper客户端（RM）读取数据是否超出其Buffer上限。
- 问题现象：RM日志内存在异常，提示Zookeeper error len*** is out of range!或Unreasonable length = ***。
- 处理方法：在TM服务管理的YARN服务的配置页面，单击yarn-env页签，更新参数yarn_resourcemanager_opts的参数值为-Djute.maxbuffer=值，此处的值需与zookeeper服务的zookeeper-env中的Djute.maxbuffer参数值保持一致，然后重启RM。
- ZooKeeper服务端写入数据是否超出其Buffer上限。
- 问题现象：ZooKeeper日志内存在异常，提示Exception causing close of session 0x1000004d5701b6a: Len error ***。
- 处理方法：ZooKeeper服务各节点新增或更新配置项-Djute.maxbuffer= (单位：bytes) ，将Buffer上限调大超过异常显示的长度。
NM组件OOM如何处理
- Java heap space或GC overhead limit exceeded或频繁FullGC。
- 直接原因：JVM堆空间不足，NM进程内部对象无法获取到足够的资源，并且在抛出OOM之前已经进行过一轮或多轮Full GC回收了失效的对象，仍无法获取足够的堆空间用于分配。
- 原因分析：NM进程中的常驻对象不多，一般只包含当前节点、运行应用、执行任务容器（Container）等基本信息，这部分占用空间不会很大。可能占用空间较大的是External Shuffle Service的Cache和Buffer，这部分受Shuffle Service相关配置（例如Spark：spark.shuffle.service.index.cache.size或spark.shuffle.file.buffer，MapReduce：mapreduce.shuffle.ssl.file.buffer.size或mapreduce.shuffle.transfer.buffer.size等）影响，并且与使用了Shuffle Service的运行应用数（或执行任务容器数）成正比。这些信息占用的堆空间随着使用Shuffle Service应用数或任务容器数的增大而增大，因此对于规格较大可运行任务较多的节点需要保证NM进程的内存配置也较大（建议最小不低于1 GB）。
- 解决方案：如果节点资源足够，建议适当增大NM堆内存（yarn-env.sh配置项YARN_NODEMANAGER_HEAPSIZE）。检查Shuffle Service相关配置是否合理，例如Spark Cache配置不应该占用大部分堆内存。
- Direct buffer memory
- 直接原因：堆外内存溢出导致的OOM，通常与External Shuffle Service有关，例如有的Shuffle Service服务的RPC调用使用了NIO DirectByteBuffer，就会用到堆外内存。
- 原因分析：堆外内存跟使用ShuffleService的应用数或任务容器数成正比。对于使用Shuffle Service的任务较多的节点，需要确认NM进程的堆外内存配置是否过小。
- 解决方案：检查堆外内存配置-XX:MaxDirectMemorySize（yarn-env.sh配置项YARN_NODEMANAGER_OPTS）是否合理。无此配置时默认与堆内存大小相同，不合理时适当调大堆外内存空间。