集群版本：HDP3.1.5

Hadoop版本：Hadoop3.1.1

源码地址：https://github.com/hortonworks/hadoop-release/tree/HDP-3.1.5.152-1-tag

一、前置知识

​ 大家都知道hadoop的核心组件是HDFS和YARN，HDFS负责存储，YARN负责计算资源管理，今天要重点扯一扯YARN。YARN的架构跟众多分布式架构一样是主从式，为了维护可靠性，ResourceManager（RM）支持High Available（HA）功能。在所有人的认知中，只要是主从架构，挂了一个slave节点或master节点，框架内部的容错机制都会保证整个系统的正常运行，加上下游的计算应用的重试机制，甚至对用户无感知。貌似所有人都关心一种情况，就是某个或者某种类型的节点挂掉，但是，还有没有其它情况呢？非死即生？不，还有一种叫stop the world生不如死，类似jvm的gc，这也是java生态框架最头疼问题之一。当然，今天要讲的不是gc，而是另一种情况下的java进程stop the world导致的严重问题——锁。

为什么需要锁

RM作为资源管理服务，必然要维护存储资源的信息，最简单的，比如Container被客户端申请分配，多线程的情况下，要保证Container数值的准确性，多线程下客户端要申请资源，会对数值进行更改，避免可能会出现数据不一致的问题，因此对此类资源的操作必须要加锁。在RM相关的代码中，有大量的加锁操作，在hadoop2.x中，RM对资源操作的锁都是最原始的syncrinized锁，而在hadoop3.x中，社区考虑到性能问题，把syncrinized锁全部换成了ReentrantReadWriteLock锁。

ReentrantReadWriteLock

ReentrantReadWriteLock可以多个Thread可以同时进行读取操作，但是同一时刻只允许一个Thread进行写入操作，而synchronized 不论读写，只要线程进入synchronized代码就互斥，所以，会出现一个线程读另一个线程不能进入的现像。ReentrantReadWriteLock里其实是加了两把锁，写锁排斥读、写，读锁只排斥 写，所以能达到并发读的效果，克服了synchronized 读互斥的缺点，所以说 ReentrantReadWriteLock比synchronized 快，这也是hadoop3.x版本中优化中对锁原因。

二、事发背景

​ 考虑成本问题公司今年迁移到新集群，由原来的cdh5.13和hdp2.6两个集群（都是hadoop2.x）迁移到HDP3.1.5，最后一个开源版本，打包的组件版本都比较新，众多新特性等待发掘，不至于技术基础上落后。迁移之初，业务并没有从其余两个集群完全迁移过来，迁移过来的业务也并没有对外服务，考虑到中间磨合过程。俗话说小病重启，大病重装，某一天，突然发现所有任务都提交不到yarn上去，正在运行的任务也无法结束，但是yarn的8088 web ui能够正常打开。看RM的log也没看到任何报错信息，于是直接重启RM，一切恢复正常。我大意了啊，没有进一步排查，这好吗？这不好。之后的一段时间里，貌似平静许多，后面才知道，同样的情况原来越来越频繁，运维小哥哥每天凌晨偷偷起来重启RM保障集群稳定，传说中的人肉运维。随着集群迁移的完成，所有业务正式上线，每天在yarn上跑的任务越来越多，好几万个实例。然鹅RM出现这种情况的频率从一周一次变成几个小时一次，啪的一下又hang住了，挂掉还好，会主备切换，但是hang住后zkfc并不会判断active节点不可用，所以不会切换，几百上千个任务卡住无法运行，严重影响业务，导致集群完全不可用！！濒临奔溃边缘！看样子Hadoop3.X显然是有bear而来不讲武德！

三、问题分析

• 分析日志

  出问题，第一时间看日志，我们分析了每一次出问题时候的RM日志，基本的现象是，RM hang住前，控制container生命周期的打印的log越来越少，比如申请、分配、完成、释放等等，等到hang住后，这些日志完全没打印了，也没有任何报错信息，没结果。

• 分析监控

  接着我们把RM的所有监控metrics都看了个遍，包括rpc、gc、cpu、内存、网络、资源分配等等，包含了RM大部分常用的指标和RM所在服务器的指标，大概上百个，我们分析出问题的那一刻指标的异动情况，中间只要有个别指标的异常，都刨根问底的查到低，最后也没查出个所以然。

• 分析任务

  为了找出RM hang住的原因，无所不用其极啊，甚至有人把调度任务跟出事的时间点扯上关系，看是不是某些在yarn上跑的特殊的任务导致RM处理问题，在之前hadoop2.x中跑任务从来没出过这样的问题。然鹅，还是没有结果。

• 分析现象

  每次出问题的时候，RM的webui能够正常打开，但是有个地方一直不会跳转，如下图：

  

  终于有了突破口，这个问题跟Scheduler有关！

• 线程堆栈分析

  一般非jvm gc导致的进程卡死的问题，都是线程问题。查了一圈关于死锁问题分析的资料，可参阅：

  除特别声明，本站所有文章均为原创，如需转载请以超级链接形式注明出处：SmartCat's Blog