HBase性能调优

欢迎转载，请注明：http://blog.csdn.net/oozie123

1 操作系统

1.1 内存

内存，内存，内存，别让HBase挨饿。

1.2 64-bit

用64位平台(和64位的JVM)。

1.3 交换区

小心交换区，设置swappiness为0。

2 网络

避免由于网络原因降低Hadoop和HBase集群性能，最重要的是考虑我们使用的交换硬件，当集群规模增大到2~3倍时，可能造成严重问题。
该着重考虑的因素如下：

• 设备的转换能力
• 系统连接数量
• 上行带宽容量

2.1 单交换机

单交换机在配置汇总最重要的是硬件的交换能力是否能够处理所有系统的连接。某些底价位的硬件拥有比较慢的交换能力而不能充分利用。

2.2 多交换机

在体系结构中，多交换机有潜在的危险。通常拥有1Gb上行带宽的低价交换机从一个切换至另一个时，这点经常成为一个集群通信的瓶颈。特别是运行MapReduce 作业时，通过上行通信，大量的读写数据，很容易达到饱和。
缓解这个问题相当的简单，可以用以下几种方式完成：

• 尝试运用合适的硬件应对相应集群规模
• 运用拥有更大端口的单交换机，例如48端口而不是2 * 24端口
• 增加交叉开关的带宽

2.3 多机架

多机架配置携带潜在的问题，由于多交换机，从两个方面有损性能：

• 比较差的交换能力
• 上行传递数据到另一个机架，性能不足

2.4 网络接口

是否所有网络接口都是正常？

2.5 网络一致性和分区容忍

HBase支持网络一致性和分区容忍，参见：http://codahale.com/you-cant-sacrifice-partition-tolerance/。

3 Java

3.1 垃圾回收器和HBase

3.1.1 长GC停顿

在他的演讲Avoiding Full GCs with MemStore-Local Allocation Buffers，Todd Lipcon 描述了在HBase中两种常见的stop-the-world垃圾回收，特别是在装载，CMS失败模式和老年代堆碎片引起。
描述第一个问题，通过添加-XX:CMSInitiatingOccupancyFraction和设置它比默认值小，就可以早于默认值启动CMS了。开始于60%或者70%(阀值你调得越低，更多的GC需要回收，更多的CPU需要使用)。为了描述第二种碎片问题，Todd添加了一个实验性的配置，(MSLAB)，在HBase 0.90.x必须显示的指示为true(Apache 0.92.x HBase已经默认配置为true)。在你的集群配置中设置hbase.hregion.memstore.mslab.enabled为true，从幻灯片中显示可以看出，在碎片时，最近的JVMs运行良好，所以确保运行该项配置在你的集群中。意识到当它们enabled时，每一个MemStore实例都会占据一个MemStore实例的内存，如果有成千上万的regions或者很多regions拥有相当多的列簇。MSLAB需分配的内存将占据你集群内存很大一部分，极端地可能造成内存溢出。在这种情形下，可以每个RS的regions数或者降低它使用的内存。
如果你在一个热点写的情形，检查 HBASE-8163 MemStoreChunkPool: An improvement for JAVA GC when using MSLAB。它描述了在写很繁重时，降低年轻代GC使用量。如果你没有安装HBASE-8163，你可以尝试提升年轻代GC的次数。可以在hbase-env.sh中，将-XX:PretenureSizeThreshold值调到比hbase.hregion.memstore.mslab.chunksize小，以至于MSLAB的分配发生在老年代空间而不是在年轻代空间。你这样做是由于MSLAB的分配更像总是在老年代，而不是花费代价在之后的s0,s1 eden空间，节省了大量YGC移动和直接在老年代空间分配。
参看更多有关GC日志，参照 JVM Garbage Collection Logs。
考虑启用 off-heap Block Cache，会有效的减少GC次数，参见 Block Cache。

4 HBase配置

请参考推荐配置。

4.1 管理合并

对于大型系统，有必要考虑compactions与splits。

4.2 hbase.regionserver.handler.count

请参考hbase.regionserver.handler.count。

4.3 hfile.block.cache.size

请参考hfile.block.cache.size，为每个RegionServer进程设置内存。

4.4 Blockcache预取选项

HBASE-9857添加了一个新的选项去预取HFile的内容，当CF或者RS设置了该选项，并且开启了BlockCache。这个选项在HBase 0.98.3和之后的版本才能使用，它的目的在于当缓存开启后，尽可能快地读取缓存，运用in-memory表数据，不计算缓存丢失率。这个非常有利于快速的读取，然而如果预加载数据没有进入BlockCache，不是个好主意。当所有数据都在BlockCache时，则会很好地优化IO。
在列族上使能欲取选线，你可以运用HBase shell或者API。
Enable Prefetch Using HBase Shell

hbase> create 'MyTable', { NAME => 'myCF', PREFETCH_BLOCKS_ON_OPEN => 'true' }

Enable Prefetch Using the API

// ...
HTableDescriptor tableDesc = new HTableDescriptor("myTable");
HColumnDescriptor cfDesc = new HColumnDescriptor("myCF");
cfDesc.setPrefetchBlocksOnOpen(true);
tableDesc.addFamily(cfDesc);
// ...

4.5 hbase.regionserver.global.memstore.size

参考hbase.regionserver.global.memstore.size，这个内存被调整依赖于RS进程的需要。

4.6 hbase.regionserver.global.memstore.size.lower.limit

参考hbase.regionserver.global.memstore.size.lower.limit，这个内存被调整依赖于RS进程的需要。

4.7 hbase.hstore.blockingStoreFiles

参考hbase.hstore.blockingStoreFiles，如果在RS logs阻塞了，则最好增加它的值。

4.8 hbase.hregion.memstore.block.multiplier

参考hbase.hregion.memstore.block.multiplier，如果内存充足，调大此参数。

4.9 hbase.regionserver.checksum.verify

HBase读写数据时，会验证校验和，参考hbase.regionserver.checksum.verify。

4.10 优化callQueue 选项

HBASE-11355 介绍了几个callQueue调优机制，可以增加性能。参考Tuning callQueue Options。