hbase-0.20.6数据写入服务端代码性能瓶颈分析

目前我的实际配置是4台8核CPU，装4个regionServer，同时读写CPU load维持在4左右，iostat查看，数据写入率也很低。

所以只能从代码层面粗略分析下：

其实hbase写入的过程大方向还是比较简单的：

1.如果有必要刷新MemStoreMemory，这个过程会短暂的持有锁，因为需要做一些CPU中的计算，（我个人觉得问题不是很大），因为作为大头的compactionRequested是异步线程去执行的。

2.写入到MemStoreMemory，这边会持有splitsAndClosesLock的读锁，不过该锁只在close的时候会去获取写锁。

3.接着持有updatesLock读锁。这把锁就很危险了，因为前面讲过，如果flushcache的事件被触发的话，那么flushRegion的时候就会拿到updatesLock读锁。这边就会卡住很长一段时间了。

4.将数据写入到memStoreMemory，这个过程在begin和complete阶段会对writeQueue进行同步。不过应该不是性能瓶颈的关键。

  

 

接下去是分析写的过程：

 

在读取的时候获取scanner的时候会持有newScannerLock读锁。但是在flushcache的时候会持有newScannerLock写锁，这边也是个严重的问题。

 

总结：

分析了以上过程，关键的问题还是在于MemStoreMemory太小，不断刷新，在写入的时候导致updatesLock处卡住。读取会在newScannerLock处卡住。

 

要解决这个问题就得增加MemStoreMemory的大小，并且增加机器数量，否则只能是杯水车薪了。。。

 

应该是flush影响读和写。

split影响写

那么, 我们可以通过减少flush的过程（但是会增加单次flush时间）, 达到提升读的性能, 牺牲部分写入的时间

 

具体是否这样稍后回去实际跑测一下再回来阐述。