HBase写入性能分析及改造.docVIP

HBase写入性能分析及改造—multi-thread flush and compaction(约能提高两到三倍吞吐量，带压缩测试) 最近对HDFS底层做了许多优化，包括硬件压缩卡，内存盘及SSD。 在出测试报告时发现老问题，HBase写入速度不稳定，这个大家都习以为常了吧，就是压测时，只要row size稍小一点，不管你怎么压，HBase的RegionServer总是不愠不火特淡定。有些人就怀疑是磁盘到瓶颈了？还有些人怀疑是不是GC拖累了？ 总之网上大部分测试都是黑盒测试嘛，大家也就乱猜呗。 下面我仔细来分析下原因，并解决掉问题，详细的测试数据在/kalaamong/article/details/7290192，对数据感兴趣的同学可以直接跳过下面的内容。 大概全套问题都解决之后写入通量提高两到三倍。 在压测时HRegionServer的Handler很多情况下都被卡在reclaimMemStoreMemory() ps:这个方法在region数目过多时淘宝庄庄说过这个问题，会影响put速度。 因为他每次都会调这一段代码，当有几千上万个region时。。。。。每次put都检查自然有问题，不过这个相对于后面的事情是小问题了，先放这。 [java] view plaincopy public long getGlobalMemStoreSize() { long total = 0; for (HRegion region : onlineRegions.values()) { total += region.memstoreSize.get(); } return total; } 下面这段展示了这个方法。 [java] view plaincopy public synchronized void reclaimMemStoreMemory() { if (isAboveHighWaterMark()) { lock.lock(); try { while (isAboveHighWaterMark() !server.isStopped()) { wakeupFlushThread(); try { // we should be able to wait forever, but weve seen a bug where // we miss a notify, so put a 5 second bound on it at least. flushOccurred.await(5, TimeUnit.SECONDS); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } } finally { lock.unlock(); } } else if (isAboveLowWaterMark()) { wakeupFlushThread(); } } 其中flushOccurred.await(5, TimeUnit.SECONDS);这一部分将所有写入线程都block了，但这也不完全怪flush做得慢，我们实际压测时，flush还是很快的，只是compact不及时，flush就会被阻塞。 参这篇jira的内容 /jira/browse/HBASE-2646 /jira/browse/HBASE-2981 /jira/browse/HBASE-2832 run YCSB写入压测时，HBase有明显的停顿，写入性能有跳变。在EMC一篇关于hypertable和HBase的测试中，提到HBase的性能被GC所累，我觉得他们有可能错误地把 flush和compaction中的停顿当作JAVA gc了。因为在给RegionServer分配24GB内存时，GC的时间很短（毫秒级）。 第一步：为flush添加线程池 HBase flush memorystore时是由一个线程顺序将数据 hbase.hstore.blockingStoreFiles （）同时flush时会获取Region writeLock的writeLock().来做snapshot,而所有的