Hadoop NameNode性能故障排查，超万亿数据库排查分享

一、项目介绍

1.事件起因：

近日客户反馈我们开发的自研数据库LSQL突然性能变差，之前秒级响应的数据查询与检索，现在却总是在“转圈”，响应速度大幅下降。同时事件发生的非常突然，先前没有任何征兆，已经在现场的同事首先排除了是由于业务变动造成的系统问题，但是初步检测之后并未发现问题。作为自己创立公司后第一个接到的万亿数据体量的大项目，我自身也非常重视，马上第一时间奔赴现场。

2.平台构架介绍：

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

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

二、排查过程

1.初步定位问题

在排查之前先说点题外话，话说我在创业之前在腾讯做Hermes系统，每日接入的实时数据量就已经达到了3600亿/天，之后更是达到了每日近万亿条数据的实时导入。因此面对当前每日500-1000亿规模的系统，我感觉伤害性不大，侮辱性极强…

言归正传，为了快速定位问题，还没出发之前我就跟现场要了一些日志和jstack，初步定位是hadoop NameNode的瓶颈，而NN的优化我们此前也做了很多次，别无其他，唯手熟尔。

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

2.尝试调整log4j

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

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

（2） 问题分析
很明显，在记录log上存在瓶颈，阻塞的时间太久。

1. 记录的log4j不应该加【%L】，它会创建Throwable对象，而这个在java里是一个重对象。

2. 日志记录太频繁，刷盘刷不动。

3. log4j有全局锁，会影响吞