YARN常见问题与常用配置
常见问题
YARN集群还有资源，为什么部分任务还是一直处于ACCEPT状态？
大数据集群还剩有很多资源，部分任务还是一直处于ACCEPT状态。首先，处于ACCEPTED状态则说明ApplicationMaster没有创建，很大概率和资源有关。比较常见的原因有两个：
- 集群的AM资源不足
yarn资源划分为AM资源和计算资源，AM资源顾名思义是专门为ApplicationMaster准备的资源，当集群中AM的资源用尽之后，剩余的任务则无法创建ApplicationMaster，即使还有剩余的计算资源。所以此时可适当调整AM资源所占的比例来使任务继续执行。 - 相应的队列资源不足
队列资源不足也会导致任务处于ACCEPTED状态，有人可能会问，队列资源我分配的是最大100%，为什么还不会去占用集群剩余的资源呢?看下一问题。
还有一种可能，多与集群外客户端有关，是客户端无法与YARN节点正常通信造成的。具体的做法参考《Spark提交HDP YARN任务》。
队列设置最大可用资源为100%，但集群资源始终无法占满
当使用一个用户高负荷执行任务到某个队列时，即使该队列配置的可用资源为100%，但任务始终无 法占满全部资源。该问题为用户因子参数影响。yarn为了避免一个用户占据所有资源，增加了用户因子这样一个参数，该参数可以限制一个用户能够占用队列资源的多少。下面举个栗子：
AB两队列，A/B最小容量各为50%，最大容量均为100%。
yarn.scheduler.capacity.root.A.user-limit-factor=1； B队列空闲，A队列满任务运行时会发现资源仍旧不能充分占用。
原因：user-limit-factor=1，通过计算公式min(capacity*user-limit-factor,maximum-capacity)，该用户能拿到A队列的最大资源为min(50%*1,100%)，集群50%的资源。增大user-limit-factor即可实现资源的充分利用。
Timeline Server是什么服务，有什么用？
引用官方的描述——持久化应用特定信息和保存已完成应用的相关信息 ，通俗的理解就像是mapreduce的Job Historyserver，保存应用的相关信息。目前有1.5版本和2.0版本，1.5使用leveldb的形式将 数据保存在本地，2.0则存储在内嵌或者分布式的HBase中，2.0性能和功能比1.5提升较多，但由于引入HBase，所以故障率也有所升高。
可以不用，不影响作业执行。
报错Connection reset by peer
连接断开后，读和写操作引起的异常。常见的原因有以下几点：
- 防火墙未关（关闭防火墙）
- ulimit值太小 （增大系统上ulimit的值）
- nm心跳丢失 （检查集群网络、agent或重启NodeManger等等）
开启kerberos后，执行任务报错Operation not permitted？
main : run as user is ambari-qa
main : requested yarn user is ambari-qa
Error setting supplementary groups for user ambari-qa: Operation not permitted
此问题是setuid操作被阻止导致，存在nosuid或者挂载情况。使用root用户启动NM时，错误消失。参考链接：
https://henning.kropponline.de/2017/02/05/yarn-secure-container/
开启cpu调度后，执行任务报错run as user is nobody?
此问 题 官 方 有 相 关 介 绍 。 是 因 为 开 启 cpu 调 度 之 后 ， container-executor 的主类由DefaultContainerExecutor(DCE)转变为LinuxContainerExecutor(LCE)，而如果在非安全情况下，默认LCE使用nodoby用户提交作业。可以通过以下两个配置实现其他用户提交。
nobody
请参考官方文档：
https://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yarn-site/NodeManagerCgroups.html
TimelineServer Reader服务启动报错？
TimelineServer Reader服务启动时报错，主要是由于HBase造成的，包括与HBase的交互，HBase与zk的 交互，所以出现问题的概率也比较大。
首先TimelineServer有两类方式使用hbase，一类是内嵌的HBase， 另一类是外部的HBase。内嵌的HBase又有两种启动HBase的方式，第一种是container的形式启动HBase，第二种是使用HBase命令行的形式启动。开源版本的两者之间的选择是判断每个NM节点资源大于10G，总集群资源大于50G时选择使用第一种，否则使用第二种。
RM和NM服务进程正常，但RM识别不到NM
RM和NM服务进程正常，但RM却识别不到NM，主要是和没有创建local dir或者local dir下面没有NM的相关目录文件导致。第一步应检查local dir目录是否存在，如果存在再检查该目录下是否有以下目录：
|_filecache
|_nmPrivate
|_usercache
local dir及下面的目录均为nm自动生成，创建过程可能会存在延迟。
新安装的集群YARN服务无法启动
Web页面的现象：
安装时ResourseManager，check状态报红色。
重启启动ResourseManager时有短暂启动标识，但随后立即转为停止状态。
查机器上/var/log/hadoop-yarn下的ResourseManager日志，可见明显报错：For input string:”undefined” ,由此追溯到与Zookeeper有关。
排查到集群服务的安装顺序为YARN早于zookeeper，因此可认为yarn安装时需要写入zk的数据不存在于zk中，因此yarn在读取时读到一个undefined，此处应为一个数字，造成了解析错误。
解决办法：
由此，依次关闭所有的YARN服务，因为这是新安装集群，没有任何业务运行，故选择卸载yarn服务进行重新安装即可。
YARN的常用配置
| RM参数名 | 解释/作用 |
|---|---|
| yarn.resourcemanager.address | ResourceManager 对客户端暴露的地址。客户端通过该地址向RM提交应用程序，杀死应用程序等。 |
| yarn.resourcemanager.scheduler.address | ApplicationMaster通过该地址向RM申请资源、释放资源等。 |
| yarn.resourcemanager.resource-tracker.address | NodeManager通过该地址向RM汇报心跳，领取任务等。 |
| yarn.resourcemanager.admin.address | 管理员通过该地址向RM发送管理命令等。 |
| yarn.resourcemanager.webapp.address | ResourceManager对外web ui地址。用户可通过该地址在浏览器中查看集群各类信息。 |
| yarn.resourcemanager.scheduler.class | 启用的资源调度器主类。目前可用的有FIFO、Capacity Scheduler（默认）和Fair Scheduler。 |
| yarn.scheduler.minimum-allocation-mb | 单个Container可申请的最小/最大内存资源量。比如设置为1024和3072，则运行MapRedce作业时，每个Task最少可申请1024MB内存，最多可申请3072MB内存。 |
| yarn.scheduler.maximum-allocation-mb | |
| yarn.scheduler.minimum-allocation-vcores | 单个Container可申请的最小/最大虚拟CPU个数。比如设置为1和4，则运行MapRedce作业时，每个Task最少可申请1个虚拟CPU，最多可申请4个虚拟CPU。默认情况下，YARN是不会对CPU资源进行调度的，你需要配置相应的资源调度器让你支持。 |
| yarn.scheduler.maximum-allocation-vcores | |
| yarn.resourcemanager.nodemanagers.heartbeat-interval-ms | NodeManager心跳间隔。 |
ResourceManager的配置
| NM的参数： | 解释/作用 |
|---|---|
| yarn.nodemannager.resource.memory-mb | NodeManager总的可用物理内存。注意，该参数一旦设置，整个运行过程中不可动态修改。另外，该参数的默认值是8192MB，即使你的机器内存不够8192MB，YARN也会按照这些内存来使用 |
| yarn.nodemanager.resource.cpu-vcores | 表示该NodeManager节点上YARN可使用总的虚拟CPU个数，注意，目前推荐将该值设值为与物理CPU核数数目相同。如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物理CPU总数。 |
| yarn.nodemanager.vmem-pmem-ratio | 使用单位物理内存可分配的虚拟内存量，默认2.1； |
| yarn.nodemanager.local-dirs | 中间结果存放位置，类似于1.0中的mapred.local.dir。注意，这个参数通常会配置多个目录，已分摊磁盘IO负载。 |
| yarn.nodemanager.log-dirs | 日志存放地址（可配置多个目录）。 |
| mapreduce.map.memory.mb | 是否启用日志聚合功能，日志聚合开启后保存到HDFS上。 |
| mapreduce.reduce.memory.mb | 是否启用日志聚合功能，日志聚合开启后保存到HDFS上。 |
NodeManager的配置
| 日志参数： | 解释/作用 |
|---|---|
| yarn.log-aggregation-enable | 是否启用日志聚合功能，日志聚合开启后保存到HDFS上。 |
| yarn.nodemanager.log.retain-seconds | NodeManager上日志在本地最多存放时间（不启用日志聚集功能时有效）。 |
| yarn.log-aggregation.retain-seconds | 聚合后的日志在HDFS上保存多长时间，单位为s，例如设置为86400，24小时 |
| yarn.log-aggregation.retain-check-interval-seconds | 删除任务在HDFS上执行的间隔，执行时候将满足条件的日志删除（超过上述参数设置的时间的日志），如果是0或者负数，则为上面参数设置值的1/10，上例值在此处为8640s。 |
| yarn.nodemanager.remote-app-log-dir | 当应用程序运行结束后，日志被转移到的HDFS目录（启用日志聚集功能时有效），修改为保存的日志文件夹。 |
| yarn.nodemanager.remote-app-log-dir-suffix | 远程日志目录子目录名称（启用日志聚集功能时有效）。 |
YARN的日志配置
YARN Capacity调度队列的参数
YARN调度队列Capacity-参数
点：YARN Debug，YARN配置
线：YARN
面：资源调度
