前言：

本文章主要用于记录日常案例分析，记录因为业务的频繁写操作导致的Hadoop集群访问雪崩的故障，以用于总结问题定位方法（从事大数据开发工作以来，写了很多文章都存储在了个人记事本里了，心血来潮，梳理一下）

项目场景：

Hadoop版本：Apach hadoop 2.6.0集群规模：2+2000+节点数据规模：接近6万亿，存储达10PB

问题描述

突然一天，现场运维人员反馈，集群数据入库相较于以往慢了很多，数据严重积压，Spark、Hive任务大面积失败，即使成功的任务，时间耗时上也长了很多，集群基本处于不可用的状态，影响极大。

原因分析：

提示：无论是hadoop、spark、hive还是其他组件，出现慢的问题，首先排除业务影响，另外要使用好jstack、jmap等性能分析工具，堆栈信息是最好的性能分析手段。

监控分析 根据问题描述，首先要观察监控大屏的变化（监控视图未展示） Spark、Hive相关监控 正常： Spark、Hive相关组件的TCP连接数、内存使用量等并未发现异常，且并未发现进程有FGC情况的发生，暂时排除组件本身的影响导致。 ResouceManager、Datanode等监控 正常：RM等相关监控正常 异常：Datanode相关监控可以发现了蛛丝马迹，Block有明显的增减现象，但是还不能完全确定集群慢是不是该现象导致的。 Namenode组件相关监控 异常：DN、NN之间交互频率增高、NN的请求频率直线上升，其他指标也出现了莫名异常。 总结：从监控层面看，集群慢是由于hadoop本身导致的，接下来重点排查NN、DN等 日志分析 从namenode的打印日志来看，瓶颈在于namenode 堆栈分析 从堆栈日志可以发现，在集群慢的周期内，出现了大量锁等待现象。通过监控数据结合堆栈信息可以看出，正是由于有大量的namenode rpc请求拥有该锁，迟迟不能释放，导致其他线程一直处于等待状态，进而导致大量线程堵塞。 源码跟踪

ContentSummary getContentSummary(final String src) throws IOException {

checkOperation(OperationCategory.READ);

final String operationName = "contentSummary";

boolean success = true;

ContentSummary cs;

final FSPermissionChecker pc = getPermissionChecker();

readLock();

try {

checkOperation(OperationCategory.READ);

cs = FSDirStatAndListingOp.getContentSummary(dir, pc, src);

} catch (AccessControlException ace) {

success = false;

logAuditEvent(success, operationName, src);

throw ace;

} finally {

readUnlock(operationName);

}

logAuditEvent(success, operationName, src);

return cs;

}

从代码层面也证实了HDFS NameNode内部的单一锁设计，每个请求需要拿到这个锁，然后让NN 去处理这个请求，这里面就包含了很激烈的锁竞争。因此一旦说NN的这个锁被一个大的写操作(比如大目录的删除)持有很长时间的话，其它用户的任务将会马上受到影响。 备注：关于Namenode单一锁机制，笔者会在下一章节单独梳理。

解决方案：

解决燃眉之急：该问题的触发就是由于业务大量删除文件导致，因此建议业务优先停止该操作。 官方Patch注入：结合官方的HDFS-7980、HDFS-7213等patch，打补丁包，测试验证后，问题得以解决，集群也不卡了，非常流畅（这也说明这就是hadoop2.6版本的bug）。 参数优化：

参数列表解释dfs.blockreport.intervalMsecDatanode会定期将当前该结点上所有的BLOCK信息报告给NameNode，该参数就是控制这个报告时间间隔，可以调大dfs.namenode.replication.intervalNN周期性计算DN的副本情况的频率，可以调大dfs.namenode.invalidate.work.pct.per.iteration减少扫描节点数量dfs.heartbeat.intervalDN的心跳间隔，秒

其他参数可以参考 https://www.cnblogs.com/peizhe123/p/5540845.html

问题思考：

Namenode的单一锁机制显得尤为“重”，后面会单独拿出一个模块梳理该部分，非常重要！另外离线集群所有组件目前也进行了全面升级，集群性能提升了35%左右。

Hadoop：3.2.3Spark：3.2.1Hive：3.1.3

参考阅读

评论可见，请评论后查看内容，谢谢！！！
 您阅读本篇文章共花了：