记一次yarn导致cpu飙高的异常排查经历
yarn就先不介绍了,这次排坑经历还是有收获的,从日志到堆栈信息再到源码,很有意思,下面听我说
问题描述:
集群一台NodeManager的cpu负载飙高。
进程还在但是看日志已经不再向ResourceManager发送心跳,不断重复下文2的动作。
心跳停止一段时间后会重连上RM但是cpu仍然很高,再过一段时间心跳再停,一直循环。
NodeManager的日志解析
1.NM的localizing过程
localizing:container开始从hdfs下载resource,hdfs文件的状态从INIT变成DOWNLOADING。
2018-08-25 16:15:38,592 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.LocalizedResource:Resource hdfs://mycluster/user/hdfs/.staging/application_1444990016246_29569/libjars/avro-mapred-hadoop2.jar transitioned from INIT to DOWNLOADING
2.无法删除
这里异常开始了。
container在localizing过程中被stop或者kill,导致hdfs文件状态保持为DOWNLOADING。
non-zero refcount表示当前没有其他container在使用这个资源,说明这个资源将无法删除。
2018-08-25 19:15:38,592 ERROR org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.LocalResourcesTrackerImpl: Attempt to remove resource: { { hdfs://mycluster/user/hdfs/.staging/application_1444990016246_29569/libjars/avro-mapred-hadoop2.jar, 1448139497492, FILE, null },pending,[],920074451410033,DOWNLOADING} with non-zero refcount
3.CancellationException
任务已经被kill所以报了CancellationException
2018-08-25 19:25:34,592 WARN org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: {...}failed;
java.util.concurrent.CancellationException
4.恢复
一段时间后状态从DOWNLOADING转为FAILED,hdfs资源可以删除
2018-08-25 20:15:38,592 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.LocalizedResource:Resource hdfs://mycluster/user/hdfs/.staging/application_1444990016246_29569/libjars/avro-mapred-hadoop2.jar(->/data/nm-local-dir/usercache/hadoop/filecache/5432524/avro-mapred-hadoop2.jar) transitioned from DOWNLOADING to FAILED
5.删除
删除本地缓存的文件(可能已损坏)
2018-08-25 19:15:38,592 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.LocalResourcesTrackerImpl:Removed /data/nm-local-dir/usercache/hadoop/filecache/5432524/avro-mapred-hadoop2.jar from localized cache
6.重新请求
请求的资源不在缓存中,将重新请求
2018-08-25 19:15:38,592 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.LocalResourcesTrackerImpl:Container container_152345432_4324_3_4324234 sent RELEASE event on a resource request {hdfs://mycluster/user/hdfs/.staging/application_1444990016246_29569/libjars/avro-mapred-hadoop2.jar,,,} not present in cache
原因总结
container被stop,原因可能是与外部组件rpc失败,或者任务被人为kill等等异常。导致hdfs资源异常无法删除而container又会一直尝试去删除
解决办法
1.Low的办法:
手动删除hdfs中无法删除的文件(难实现,不知道删那些文件且很多时操作麻烦)
2.高端的办法:
找到异常的位置
LocalResourcesTrackerImpl(line339)
public boolean remove(LocalizedResource rem, DeletionService delService) {
// current synchronization guaranteed by crude RLS event for cleanup
LocalizedResource rsrc = localrsrc.get(rem.getRequest());
if (null == rsrc) {
LOG.error("Attempt to remove absent resource: " + rem.getRequest()
+ " from " + getUser());
return true;
}
if (rsrc.getRefCount() > 0
|| ResourceState.DOWNLOADING.equals(rsrc.getState()) || rsrc != rem) {
// internal error
LOG.error("Attempt to remove resource: " + rsrc
+ " with non-zero refcount");
return false;
} else { // ResourceState is LOCALIZED or INIT
localrsrc.remove(rem.getRequest());
if (ResourceState.LOCALIZED.equals(rsrc.getState())) {
delService.delete(getUser(), getPathToDelete(rsrc.getLocalPath()));
}
decrementFileCountForLocalCacheDirectory(rem.getRequest(), rsrc);
LOG.info("Removed " + rsrc.getLocalPath() + " from localized cache");
return true;
}
}
ResourceState.DOWNLOADING.equals(rsrc.getState())
文件状态为DOWNLOADING则报错,可在源码中删除这个条件。
参考添加补丁:
https://issues.apache.org/jira/browse/YARN-2902
https://issues.apache.org/jira/secure/attachment/12685562/YARN-2902.patch
3.无敌的办法:
重启大法。。。重启nodemanager,spark等任务会自动failover,不会影响线上的业务
总结
这个问题和资源分配或者container的资源占用没有关系,因为是nodemanager的cpu飙高,而不是container。
产生这个问题的原因是在刚提交任务的时候,container开始初始化并且开始从hdfs拉依赖资源到本地,此时任务挂了或者container挂了(人为的或者超时等原因)。
并且此时没有其他container在使用这个资源,则这个资源就会保持在DownLoading状态,则会报上面第二个错误。
正常情况下不用理会这个报错,一段时间后会把DownLoading改为Failed,然后直接将资源删除。
但是我这里观察到的情况是DownLoading状态的文件太多,状态转换速度非常慢,甚至一直都无法转换成功,导致无法删除,日志里出现大量类似2的报错且把cpu拉得特别高偶尔出现nodemanager假死的情况。
最终的解决办法是重启。
记一次yarn导致cpu飙高的异常排查经历的更多相关文章
- 一次FGC导致CPU飙高的排查过程
今天测试团队反馈说,服务A的响应很慢,我在想,测试环境也会慢?于是我自己用postman请求了一下接口,真的很慢,竟然要2s左右,正常就50ms左右的. 于是去测试服务器看了一下,发现服务器负载很高, ...
- 系统CPU飙高,怎么排查?
cpu是整个电脑的核心计算资源,对于一个应用进程来说,cpu的最小执行单元是线程. 导致cpu飙高的原因有几个方面: cpu上下文切换过多,对于cpu来说,同一时刻下每个cpu核心只能运行一个线程,如 ...
- mongoDB cpu飙高问题
问题描述: 最近几天生产环境上的mongodb一直在报警,cpu飙高,其他如内存.iops.连接数.磁盘操作等都正常.通过定位业务,发现是由于mongodb的表其中一个查询未建立索引导致,110多W的 ...
- 你要偷偷学会排查线上CPU飙高的问题,然后惊艳所有人!
GitHub 20k Star 的Java工程师成神之路,不来了解一下吗! GitHub 20k Star 的Java工程师成神之路,真的不来了解一下吗! GitHub 20k Star 的Java工 ...
- 【面试普通人VS高手系列】CPU飙高系统反应慢怎么排查?
面试过程中,场景类的问题更容易检测出一个开发人员的基本能力. 这不,一个小伙伴去阿里面试,第一面就遇到了关于"CPU飙高系统反应慢怎么排查"的问题? 对于这个问题,我们来看看普通人 ...
- java进程CPU飙高
因为这段时间一直在弄监控,但是工作还是在进行中 因为机器不多,所以今天早上巡检了一下,看到一台生产机器上的CPU飙高 top
- 记一次查内存异常问题(续《记一次Web应用CPU偏高》)
继上一次查应用的CPU飙高问题(http://www.cnblogs.com/hzmark/p/JVM_CPU.html)过去10天了.上次只是定位到了是一个第三方包占用了大量的CPU使用,但没有细致 ...
- STORM在线业务实践-集群空闲CPU飙高问题排查
源:http://daiwa.ninja/index.php/2015/07/18/storm-cpu-overload/ 2015-07-18AUTHORDAIWA STORM在线业务实践-集群空闲 ...
- JVM进程cpu飙高分析
在项目快速迭代中版本发布频繁 近期上线报错一个JVM导致服务器cpu飙高 但内存充足的原因现象. 对于耗内存的JVM程序来而言, 基本可以断定是线程僵死(死锁.死循环等)问题. 这里是纪录一下排 ...
随机推荐
- 02-OpenLDAP配置
OpenLDAP配置 在OpenLDAP 2.4版本中,配置OpenLDAP的方法有两种:一种通过修改配置文件实现配置,另一种通过修改数据库的形式完成配置. 通过配置数据库完成各种配置,属于动态配置且 ...
- HDU ACM 1869 六度分离(Floyd)
六度分离 Time Limit: 5000/1000 MS (Java/Others) Memory Limit: 32768/32768 K (Java/Others)Total Submis ...
- [MapReduce_add_2] MapReduce 实现年度最高气温统计
0. 说明 编写 MapReduce 程序实现年度最高气温统计 1. 气温数据分析 气温数据样例如下: ++023450FM-+000599999V0202701N015919999999N00000 ...
- 最大公约数&&最小公倍数
//最大公约数(greatest common divisor),运用递归 int gcd(int a,int b){//注意a要求大于b return !b?a:gcd(b,a%b); } //最小 ...
- Sudoku 个人项目1
Github项目地址:Github 项目相关要求 随机构造出N个不重复的已解答的数独棋盘(0 < N <= 1000000) 在生成数独矩阵时,左上角的第一个数为:(学号后两位相加)% 9 ...
- 浅析JAVA中堆内存与栈内存的区别
Java把内存划分成两种:一种是栈内存,一种是堆内存. 一.栈内存 存放基本类型的变量,对象的引用和方法调用,遵循先入后出的原则. 栈内存在函数中定义的“一些基本类型的变量和对象的引用变量”都 ...
- python 之 递归
终于来到了这里,这是一座山,山那边都是神仙 定义:在一个函数里调用函数本身 最好的例子就是,求阶乘 def factorial(n): if n == 1: return 1 elif n > ...
- 面试被问http协议?这篇文章足够覆盖所有相关问题!
http使用面向连接的TCP作为传输层协议.http本身无连接. 请求报文 CRLF是回车换行 方法为GET的请求报文 方法为POST的请求报文 方法 OPTIONS:这个方法 ...
- UVA127-"Accordian" Patience(模拟)
Problem UVA127-"Accordian" Patience Accept:3260 Submit:16060 Time Limit: 3000 mSec Proble ...
- SpringMVC: web.xml中声明DispatcherServlet时一定要添加load-on-startup标签
游历SpringMVC源码后发现,在web.xml中注册的ContextLoaderListener监听器只是初始化了一个根上下文,仅仅完成了组件扫描和与容器初始化相关的一些工作,并没有探测到具体每个 ...
