记一次超万亿规模的hadoop NameNode性能故障排查过程

近日客户反馈录信数据库LSQL突然性能变差，之前秒级响应的数据查询与检索，现在却总是在“转圈”，卡住不动了。因为是突然发生的现象，现场先排除了业务变动，并未发现问题。作为数据库厂家，我立马奔赴现场，万亿级别大项目不敢小觑。

先来介绍一下该平台架构，底层采用hadoop进行分布式存储，中间数据库采用的录信lsql，数据实时导入采用kafka进行。每天的数据规模是500亿，数据存储周期为90天，一共有4000多张数据表，其中最大的单表数据规模近2万亿条记录，总数据规模将近5万亿，存储空间占8PB。

数据平台支撑的基本使用主要包括数据的全文检索、多维查询，以及地理位置检索、数据碰撞等操作。也会有部分业务会进行数据的统计和分析，会有极少量的数据导出与多表关联操作。

• 去之前信心满满

创业之前在腾讯做Hermes系统，每日接入的实时数据量就已经达到了3600亿/天，之后更是达到了每日近万亿条数据的实时导入。因为有了处理超大集群的经历，难免有些自负。面对当前每日500-1000亿规模的系统，完全没觉得自己会搞不定。

去之前跟现场要了一些日志和jstack，初步定位是hadoop NameNode的瓶颈，而NN的优化我们此前也做了很多次。所以自信满满出发，扬言一天搞定问题，两天必回，决不拖3.0版本开发日程的后腿。

下图为当时堆栈的分析情况，估计在座诸位看了都会信心满满，这很明显就是hadoop卡顿。

 

• 第一天：调整log4j---有效果但依然卡

我到现场后第一件事情就是不断的抓 hadoop Namenode的堆栈Jstack。从中得到的结论是问题确实是卡顿在NN上。此处NN是一个全局锁，所有的读写操作都在排序等待，详情如下图所示：

 

1.卡在哪里

这个锁的等待个数竟然长达1000多个，不卡才怪呢，我们再细看一下，当前拥有这个锁的线程在做什么？

 

2.问题分析

很明显，在记录log上存在瓶颈，阻塞的时间太久。

1. 记录的log4j不应该加【%L】，它会创建Throwable对象，而这个在java里是一个重对象。
2. 日志记录太频繁，刷盘刷不动。
3. log4j有全局锁，会影响吞吐量。

3.调整方案

客户的hadoop版本采用的是2.6.0版本，该版本的hadoop，在日志处理上存在诸多问题，故我们将官方明确表示存在问题的patch打了进来