yarn ResourceManager Active频繁易主问题排查

2024-09-04 17:18

本文主要是介绍yarn ResourceManager Active频繁易主问题排查,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

    • 一、故障现象
    • 二、问题分析
      • RM的HA机制分析
      • ZK问题分析
      • 部分任务状态更新失败问题分析
    • 三、解决和优化方案
      • 1. 调大 jute.maxbuffer 参数
      • 2. 修改yarn的源码
      • 3. 快速让集群恢复稳定的方法
    • 四、总结

本周三公司的yarn集群出现故障,导致两台ResourceManger频繁易主,并且许多提交到集群的任务状态为 NEW_SAVING,无法执行。这里对此次的故障排查进行一个总结。

一、故障现象

  1. 两个节点的ResourceManger频繁在active和standby角色中切换。不断有active易主的告警发出
  2. 许多任务的状态没能成功更新,导致一些任务状态卡在NEW_SAVING无法进入调度(还有许多资源空闲)

看了下ResourceManger的日志,发现大量以下错误:

org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss

在这里插入图片描述
在这里插入图片描述

从日志可以看出是在操作zk时出现了错误,并且会进行重试。RM在重试1000次后才会放弃尝试。并且从日志可以看出,这是在更新任务appattempt_1535616282827_1432747_000002的状态时发生的异常

紧接着后面还发现另外一条日志,表示此时RM的状态进入了standby:

2019-03-20 14:37:48,914 INFO org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Transitioning to standby state

RM进入standby状态前会将对应的ZK节点/yarn/ActiveStandbyElectorLock删除,然后再转到standby状态。这时两台RM同时开始竞争尝试新建/yarn/ActiveStandbyElectorLock节点,谁竞争到谁就是active。

成为active的节点又收到appattempt_1535616282827_1432747_000002的状态更新,就尝试更新zk节点的数据,然后又发生上面的错误,重试1000次后转为standby。如此一直重复下去,直到人为介入kill了该任务,集群才恢复正常。

因为是zk操作的问题,所以看了下zk的日志,也发现了异常:

2019-03-20 14:37:40,141 [myid:1] - WARN  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x16324e8243d0003 due to java.io.IOException: Len error 2186401
2019-03-20 14:37:40,142 [myid:1] - INFO  [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1007] - Closed socket connection for client /192.168.142.10:23412 which had sessionid 0x16324e8243d0003

从日志上看,只有appattempt_1535616282827_1432747_000002这个任务状态会更新失败,其他任务的状态都可以正常更新,有一些任务会因为zk连接被关闭而更新失败,这个后面解释原因。

二、问题分析

RM的HA机制分析

之前一直以为RM只有在和zk失联,/yarn/ActiveStandbyElectorLock节点断开后才会进行易主。但是这次的异常却颠覆了我的认知。于是去跟了下yarn的源码。发现还有一种情况可能导致RM从active状态切换到standby状态。

RM在进行任务状态更新时,会进行对应的zk操作,也就是将任务的相关信息存储到zk。如果这个失败,RM会进行重试,这个重试的次数可以通过yarn.resourcemanager.zk-num-retries配置,默认是1000次。当对应的zk操作失败重试达到1000次,RM就会将状态切换到standby

具体可能导致active切换成standby的操作有以下这些:

  1. storeApplicationStateInternal
  2. updateApplicationStateInternal
  3. removeApplicationStateInternal
  4. storeApplicationAttemptStateInternal
  5. updateApplicationAttemptStateInternal
  6. storeRMDelegationTokenState
  7. removeRMDelegationTokenState
  8. updateRMDelegationTokenState
  9. storeRMDTMasterKeyState
  10. removeRMDTMasterKeyState
  11. storeOrUpdateAMRMTokenSecretManagerState

所以我们上面的故障很明显就是在某个任务的updateApplicationAttemptStateInternal操作出现异常后,才导致active在两个RM节点间不断切换的。

如果配置了多个RM,客户端根据yarn-site.xml的配置会采用round-robin的方式逐个去连接RM,直到找到active 节点位置。所以即使active节点切换,在运行中的客户端也能通过这种方式重新找到新的Active RM进行连接。

ZK问题分析

上面的故障其实归根结底还是zk的问题。zk的这条日志Exception causing close of session 0x16324e8243d0003 due to java.io.IOException: Len error 2186401也很明确的表明是由于客户端发来的请求包太大,zk主动关闭了连接。

上网搜了下zk的Len error的问题,发现也有一些人碰到过。甚至找到两个相关的issue,一个是yarn的,一个是zookeeper的:

https://issues.apache.org/jira/browse/YARN-3469

https://issues.apache.org/jira/browse/ZOOKEEPER-706

其中zk的issue是说如果一个请求要注册的watcher太多,会导致Len error的问题。因此这个issue的patch是将这些watcher分成多个请求发送,这样就不会导致请求过大的问题了。刚好修复版本是3.4.7,而我们集群用的zk版本是3.4.6

yarn的issue是说之前的版本设置了过多无用的watcher,导致某个请求太大,出现Len error的问题。因此yarn这边做的修复是不在注册无用的watcher。修复版本是2.6.0,我们集群用的版本是2.7.4,因此我们集群应该不会有这个问题

因为排查时已经无法找到那个请求包的具体内容,这两个issue看上去又很有说服力。虽然yarn已经修复了注册过多无用watcher的,但是可能还有一些地方还有类似的问题呢。

本来以为问题大概就是这样了,我们已经准备升级zk版本了。突然又想到失败的zk操作是updateApplicationAttemptStateInternal,它底层的zk操作是setData,而setData是不会注册任何watcher的。因此这个问题和watcher没有任何关系。

后面继续排查,发现下面这篇博客:

https://www.jishuwen.com/d/2BBc/zh-hk#tuit

和我们的故障现象很像,于是追到了博客提到的yarn的issue:

https://issues.apache.org/jira/browse/YARN-2368

ResourceManager failed when ZKRMStateStore tries to update znode data larger than 1MB。也就是我们遇到的问题。就是要更新的任务信息过大导致的,和watcher没有关系

这issue并没有修复的版本,看了下它的patch,就是加了一个配置,用来指定jute.maxbuffer,也就是通过调大zk的阀值来避免出现该问题

部分任务状态更新失败问题分析

从日志看,只有appattempt_1535616282827_1432747_000002这个任务因为更新内容过大导致zk操作失败。但是故障时看到的现象确实许多任务状态都卡在NEW_SAVING无法更新。这是为什么呢?

通过分析日志,可以很容易得出结论。RM在更新appattempt_1535616282827_1432747_000002状态失败时,zk服务端主动断掉了连接,RM在下次重试时就会再次尝试建立连接。

因为任务状态更新用的zk连接可能是同一个,如果要更新时刚好连接被关闭了,任务肯定无法成功更新。因此才会有部分任务状态可以更新,部分任务状态无法更新的现象。

在RM的日志中我们也可以看到许多下面的Broken pipe异常:

在这里插入图片描述

三、解决和优化方案

1. 调大 jute.maxbuffer 参数

通过调大jute.maxbuffer来让zk可以接受更大的请求包而不会抛出IOException。这个参数的默认值是1M。

注意,这个不是在zk的配置文件中设置。而是作为java参数在启动zk时设置,也就是-Djute.maxbuffer=xxxx的方式

另外,根据zk的文档,这个参数在所有的客户端和zk服务端都要设置,否则会有更多的问题产生。也就是说,我们需要在yarn这边也设置这个参数。

这种方式有点治标不治本,因为我们无法知道任务信息最大可能到多少。设置过大的值也不是个好主意。最重要的是这个方案要同时对yarn和zk进行重启,风险略高。

2. 修改yarn的源码

虽然知道了问题的原因所在,但是我们还不知道为什么那个任务会产生那么大的任务信息。所以我们对zk的端口进行抓包查看正常的任务信息的请求都有多大:

在这里插入图片描述

通过抓包的结果,我们发现正常任务包的大小其实都只有几K,最高不会超过5K。所以我们打算修改yarn的源码过滤掉那些大小超过1M的任务更新请求,同时把这些大于1M的请求内容打印出来。

这样做一方面是为了避免后面因为某个任务的更新失败又导致集群出现问题,另一方面也可以观察到为什么有的任务会产生那么大的信息。

附上更新的代码,ZKRMStateStore#updateApplicationAttemptStateInternal()

    byte[] attemptStateData = attemptStateDataPB.getProto().toByteArray();//测试环境可以加上下面这个日志,实时观察各个任务信息的大小
LOG.info(String.format("attempId:%s,len:%s",attemptStateDataPB.getAttemptId(),attemptStateData.length));//如果任务信息超过了950K,就打出error日志,输出任务信息,同时直接返回,不再往zk发送请求if(attemptStateData.length > 972800){LOG.error(String.format("attemptStateData len larger than 1M.len:%s,nodeUpdatePath:%s,data:%s,attemptId:%s,Diagnostics:%s,traceUrl:%s,container%s",attemptStateData.length,nodeUpdatePath,String.valueOf(attemptStateData),attemptStateDataPB.getAttemptId(),attemptStateDataPB.getDiagnostics(),attemptStateDataPB.getFinalTrackingUrl(),attemptStateDataPB.getMasterContainer()));return;}//往zk发送请求更新任务信息if (existsWithRetries(nodeUpdatePath, false) != null) {setDataWithRetries(nodeUpdatePath, attemptStateData, -1);} else {createWithRetries(nodeUpdatePath, attemptStateData, zkAcl,CreateMode.PERSISTENT);LOG.debug(appAttemptId + " znode didn't exist. Created a new znode to"+ " update the application attempt state.");}

3. 快速让集群恢复稳定的方法

如果集群又发生了类似的问题,可以找到任务的ApplicationMaster所在的Container,然后上目标服务器将对应的Container进程kill掉,后面RM就不会再更新该任务的信息,而是将任务直接转为Kill状态。

四、总结

此次故障大概持续了2个半小时才恢复,还是刚好业务同学手动kill了那个任务的container进程,最终才没有一直切换下去。

因为之前对yarn只有原理上的认知,并没有看过yarn的代码,对yarn状态机的相关知识也了解不多。所以在故障发生时有点手足无措,不知道从何下手排查。

此刻回想起来真的很侥幸,因为这个故障不是重启一下RM就能恢复的。如果业务同学没有刚好kill那个container进程,可能我们要一直排查到分析出问题的根本原因为止,至少要多半天的时间。

后面还是要多看看集群各个组件的源码,深入了解他们的架构,争取出现问题时能更快的定位到问题并修复。

这篇关于yarn ResourceManager Active频繁易主问题排查的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1136540

相关文章

好题——hdu2522(小数问题:求1/n的第一个循环节)

好喜欢这题,第一次做小数问题,一开始真心没思路,然后参考了网上的一些资料。 知识点***********************************无限不循环小数即无理数,不能写作两整数之比*****************************(一开始没想到,小学没学好) 此题1/n肯定是一个有限循环小数,了解这些后就能做此题了。 按照除法的机制,用一个函数表示出来就可以了,代码如下

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

购买磨轮平衡机时应该注意什么问题和技巧

在购买磨轮平衡机时,您应该注意以下几个关键点: 平衡精度 平衡精度是衡量平衡机性能的核心指标,直接影响到不平衡量的检测与校准的准确性,从而决定磨轮的振动和噪声水平。高精度的平衡机能显著减少振动和噪声,提高磨削加工的精度。 转速范围 宽广的转速范围意味着平衡机能够处理更多种类的磨轮,适应不同的工作条件和规格要求。 振动监测能力 振动监测能力是评估平衡机性能的重要因素。通过传感器实时监

缓存雪崩问题

缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库,瞬间耗尽数据库资源,导致数据库无法使用。 解决方案: 1、使用锁进行控制 2、对同一类型信息的key设置不同的过期时间 3、缓存预热 1. 什么是缓存雪崩 缓存雪崩是指在短时间内,大量缓存数据同时失效,导致所有请求直接涌向数据库,瞬间增加数据库的负载压力,可能导致数据库性能下降甚至崩溃。这种情况往往发生在缓存中大量 k

6.1.数据结构-c/c++堆详解下篇(堆排序,TopK问题)

上篇:6.1.数据结构-c/c++模拟实现堆上篇(向下,上调整算法,建堆,增删数据)-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小): 2.2 C语言代码(手写堆) 2.3 C++代码(使用优先级队列 priority_queue)

【VUE】跨域问题的概念,以及解决方法。

目录 1.跨域概念 2.解决方法 2.1 配置网络请求代理 2.2 使用@CrossOrigin 注解 2.3 通过配置文件实现跨域 2.4 添加 CorsWebFilter 来解决跨域问题 1.跨域概念 跨域问题是由于浏览器实施了同源策略,该策略要求请求的域名、协议和端口必须与提供资源的服务相同。如果不相同,则需要服务器显式地允许这种跨域请求。一般在springbo

题目1254:N皇后问题

题目1254:N皇后问题 时间限制:1 秒 内存限制:128 兆 特殊判题:否 题目描述: N皇后问题,即在N*N的方格棋盘内放置了N个皇后,使得它们不相互攻击(即任意2个皇后不允许处在同一排,同一列,也不允许处在同一斜线上。因为皇后可以直走,横走和斜走如下图)。 你的任务是,对于给定的N,求出有多少种合法的放置方法。输出N皇后问题所有不同的摆放情况个数。 输入

vscode中文乱码问题,注释,终端,调试乱码一劳永逸版

忘记咋回事突然出现了乱码问题,很多方法都试了,注释乱码解决了,终端又乱码,调试窗口也乱码,最后经过本人不懈努力,终于全部解决了,现在分享给大家我的方法。 乱码的原因是各个地方用的编码格式不统一,所以把他们设成统一的utf8. 1.电脑的编码格式 开始-设置-时间和语言-语言和区域 管理语言设置-更改系统区域设置-勾选Bata版:使用utf8-确定-然后按指示重启 2.vscode

Android Environment 获取的路径问题

1. 以获取 /System 路径为例 /*** Return root of the "system" partition holding the core Android OS.* Always present and mounted read-only.*/public static @NonNull File getRootDirectory() {return DIR_ANDR

form表单提交编码的问题

浏览器在form提交后,会生成一个HTTP的头部信息"content-type",标准规定其形式为Content-type: application/x-www-form-urlencoded; charset=UTF-8        那么我们如果需要修改编码,不使用默认的,那么可以如下这样操作修改编码,来满足需求: hmtl代码:   <meta http-equiv="Conte