来源：蜘蛛抓取(WebSpider)
时间：2017-08-23 08:10
标签：
c region
当前位置： >>
hbase regionServer异常分析报告
测试环境：172.25.3.103-106，172.25.3.103 是 master 节点。 测试步骤：拔了 172.25.3.105 节点的网线。 现象描述：原先每个 regionserver 负责 25 个 region，当 172.25.3.105 节点挂了以后，它负责 的 region 会有其他 regionserver 接管，500 多万的数据，恢复时间为 6 分钟左
右。 问题分析： 1. 在 zookeeper 的 /hbase/rs 目录下维护在线的 regionserver 节点，当 zookeeper 检测 到某个节点 expiration，ServerManager 会将该节点添加到 dead servers，并提交 ServerShutdownHandler 执行 Splitting logs。 2. 将 172.25.3.105 上的 WALs 拆分成两个文件，如： 172-25-3-105%2C.7 172-25-3-105%2C.2 同时启动 task 任务，将拆分后的文件分配给 172.25.3.103 和 172.25.3.104 节点的 SplitLogWorker。 将新生成的两个 WALs 文件放入 hdfs://mycluster/hbase/oldWALs 调用 recoverLease 方法，获取新生成的 WALs 文件租约（在 hdfs 的设计中，Lease 是为了实现一个文件在一个时刻只能被一个客户端写） 。recoverLease 方法返回有 几种途径：1）成功获取租约；2）达到超时时间；3）文件关闭。在分别获取两个 路径租约的时候，第一个路径成功获取租约：recoverLease=true；另一个路径一直 获取不到租约，在重试 7 次之后，文件关闭，after 324721ms 返回，这也是恢复过 程耗时长的主要原因。第一次失败，sleep 4000ms 后重试；之后每次重试 sleep 时 间根据参数： hbase.lease.recovery.dfs.timeout 而定， 我们系统设置该值为 64000ms。 recoverLease 方法返回后，HLogSplitter 开启 writer thread，将 172.25.3.105 节点上 的 region 进行拆分，以 0bfdac9dce6ed7be99fb8f7 region 为例： a) Creating writer path= hdfs://mycluster/hbase/data/default/falcon_picrecord/0bfdac9dce6ed 7be99fb8f7/recovered.edits/0002161.temp Split writers finished 后，Submitting close of hdfs://mycluster/hbase/data/default/falcon_picrecord/0bfdac9dce6ed 7be99fb8f7/recovered.edits/0002161.temp c) Closing hdfs://mycluster/hbase/data/default/falcon_picrecord/0bfdac9dce6ed 7be99fb8f7/recovered.edits/0002161.temp d) Closed wap hdfs://mycluster/hbase/data/default/falcon_picrecord/0bfdac9dce6ed 7be99fb8f7/recovered.edits/0002161.temp e) Rename hdfs://mycluster/hbase/data/default/falcon_picrecord/0bfdac9dce6ed 7be99fb8f7/recovered.edits/0002161.temp to hdfs://mycluster/hbase/data/default/falcon_picrecord/0bfdac9dce6ed 7be99fb8f7/recovered.edits/0002281 Rename region 完成后，开启 flush ，先对本机原有的 region 进行 flush ，以 7da3ddf6e948ee2742f0cec68cf6ee93 region 为例： b)3. 4.5.6. a) b) c)d)e)f) 7.HRegionServer：periodicFlusher requesting flush for region HRegion: Started memstore flush for falcon_picrecord,094,1.7da3ddf6e948ee2742f0cec68cf6ee93. DefaultStoreFlusher: Flush into tmp file hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/.tmp/ff450d9514959bade2c121 HRegionFileSystem: Committing store file hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/.tmp/ff450d9514959bade2c121 as hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/ff450d9514959bade2c121 HStore: Added hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/ff450d9514959bade2c121 HRegion: Finished memstore flushFlush 完成后开启 major compaction， 还是以 7da3ddf6e948ee2742f0cec68cf6ee93 为 例： a) HRegion: Starting compaction on col in region falcon_picrecord,094,1.7da3ddf6e948ee2742f0cec68cf6ee93. b) HStore: Starting compaction of 3 file(s) in col of c) falcon_picrecord,094,1.7da3ddf6e948ee2742f0cec68cf6ee93. into tmpdir=hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2 742f0cec68cf6ee93/.tmp d) Compactor: Compacting hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/c892ba8a7eeae hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/3d3adcb434b7a616e6b0c8 hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/ff450d9514959bade2c121 e) HRegionFileSystem: Committing store file hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/.tmp/4eccfc22b210f2a8040a as hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/4eccfc22b210f2a8040a f) HFileArchiver: Finished archiving from hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/c892ba8a7eeae, to hdfs://mycluster/hbase/archive/data/default/falcon_picrecord/7da3ddf6e948ee2 742f0cec68cf6ee93/col/c892ba8a7eeae hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce g) 8.c68cf6ee93/col/3d3adcb434b7a616e6b0c8, to hdfs://mycluster/hbase/archive/data/default/falcon_picrecord/7da3ddf6e948ee2 742f0cec68cf6ee93/col/3d3adcb434b7a616e6b0c8 hdfs://mycluster/hbase/data/default/falcon_picrecord/7da3ddf6e948ee2742f0ce c68cf6ee93/col/ff450d9514959bade2c121, to hdfs://mycluster/hbase/archive/data/default/falcon_picrecord/7da3ddf6e948ee2 742f0cec68cf6ee93/col/ff450d9514959bade2c121 HStore: Completed major compaction of 3 files of 7da3ddf6e948ee2742f0cec68cf6ee93 into 4eccfc22b210f2a8040a当另一个 recoverLease 方法返回后，删除原先的 WALs 文件，将 172.25.3.105 上的 region 通过 round-robin 分配到其他三个 regionserver 上，AssignmentManager： Assigning 8 region(s) to 172-25-3-103 Assigning 9 region(s) to 172-25-3-104 Assigning 9 region(s) to 172-25-3-106 将分发到各个 regionserver 的 region Online： a) AssignmentManager: Handling RS_ZK_REGION_OPENING state=PENDING_OPEN b) RegionStates: Transitioned state=PENDING_OPEN to state=OPENING c) AssignmentManager: Handling RS_ZK_REGION_OPENED state=OPENING d) RegionStates: Transitioned state=OPENING to state=OPEN e) OpenedRegionHandler: Handling OPENED of 5ebe39a8fb6cb1c from 172-25-3-103, deleting unassigned node. f) AssignmentManager: Znode 5ebe39a8fb6cb1c deleted, state=OPEN g) RegionStates: Onlined 5ebe39a8fb6cb1c on 172-25-3-1039.10. HRegionServer Open 新分配的 region 后，开启 flush 和 major compaction。 疑点： 1 recoverLease 为什么会失败； 获取租约失败原因：hbase 每隔一个小时会新打开一个 WALs 文件，并将原文件关闭。新生 成的文件会一直保存打开，知道新的文件生成。客户端宕机前，最后一个 block 的 pipeline 还没建立起来，处于 under construction 或者 under recovery 状态。 NodeManager 的处理方 式是把最后一个 block 从 INode 中溢出，并且关闭文 件。 Hbase 客户端获取不到租约会一直重试，之前也已经分析过，退出的方式有三种：1）成功 获取租约；2）等待文件关闭；3）重试超时。 目前每次测试都会有文件获取租约失败的情况，等待文件关闭，但如果文件一直未关闭，就 会等到超时。超时时间为 15 分钟，设置参数为：hbase.lease.recovery.timeout。目前把该值 修改为 180s， 保证重试循环 3 次(每次循环超时时间为 64s)。 在此过程中， 读请求可能超时， 但写请求会一直阻塞(AsyncProcess.waitUntilDone)，不会丢失数据。
HBase 集群进行 RPC 操作时会抛出 NotServingRegionException 异常,从 而导致读...Region Server 上的均匀分布,而且预 先在不同 Region Server 上创建并分配了...网易视频云 HBase RegionServer宕机案件侦查_计算机软件及应用_IT/计算机_专业资料...我们就以这些异常信息作为切入点进行分析, 可以看出至少三条有用的线索,如下图...网易视频云HBase RegionServer宕机案件侦查_计算机软件及应用_IT/计算机_专业资料...我们就以这些异常信息作为切入点进行分析, 可以看出至少三条有用的线索,如下图...Region Server,提高系统 Locality) 通过上述理论分析,如果仅仅依赖 HBase 本身的 ...直到有一天, 又有另一台 RegionServer 宕机, 查看日志发现是同样的端口耗尽错误...提供的检查报告也可以看到 hbck 的结果, 日常只需要...region 没有分配(unassigned),错误分配(incorrectly ...对于 hbase regionserver 重启,不要直接 kill 进程,...Hbase 运维手册 1. region 情况 需要检查 1. region 的数量(总数和每台 regionserver 上的 region 数) 2. region 的大小 如果发现异常可以通过手动 merge ...默认: 20000 hbase.regionserver.nbreservationblocks 储备的内存 block 的数量(译者注:就像石油储备一样)。当发生 out of memory 异常的时候, 我们可以用这些内存...ntp) 3 异常处理机制测试 Hmaster 节点宕机的实验主要设计了以下几种异常情况。...&name&hbase.regionserver.restart.on.zk.expire&/name& &value&true&/value&...HBase 中 Region 分配问题的探讨在 HBase 的 cluster 中,Region 是如何分配这个问题,困扰了我很久,经过代码分析 和调试,得出了一些见解,缺点和错误请大家批评指正...hbase参数配置说明_计算机软件及应用_IT/计算机_专业资料。hbase 参数配置及优化 ...regionserver 的服务 真出现异常时,zookeeper 不会切除该 regionserver,使得很多...
All rights reserved Powered by
copyright ©right 。文档资料库内容来自网络，如有侵犯请联系客服。酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
早晨上班好好的，突然nagios报出一台regionserver挂了。顿时忙碌起来。
上去一看，从log中看到这样一条信息
04:02:22,083 ERROR org.apache.hadoop.hbase.regionserver.HRegionServer: ZooKeeper session expired
之后， regionserver就理直气壮地退出了。
于是查了下代码，看到了在org.apache.hadoop.hbase.regionserver.HRegionSever.java下这样一段代码。
* We register ourselves as a watcher on the master address ZNode. This is
* called by ZooKeeper when we get an event on that ZNode. When this method
* is called it means either our master has died, or a new one has come up.
* Either way we need to update our knowledge of the master.
* @param event WatchedEvent from ZooKeeper.
public void process(WatchedEvent event) {
EventType type = event.getType();
KeeperState state = event.getState();
<(&Got ZooKeeper event, state: & + state + &, type: & +
type + &, path: & + event.getPath());
// Ignore events if we&re shutting down.
if (stopRequested.get()) {
LOG.debug(&Ignoring ZooKeeper event while shutting down&);
if (state == KeeperState.Expired) {
LOG.error(&ZooKeeper session expired&);
boolean restart =
this.conf.getBoolean(&hbase.regionserver.restart.on.zk.expire&, false);
if (restart) {
restart();
} else if (type == EventType.NodeDeleted) {
watchMasterAddress();
} else if (type == EventType.NodeCreated) {
getMaster();
// ZooKeeper watches are one time only, so we need to re-register our watch.
watchMasterAddress();
这段注释写的很清楚了。对于一个reigonserver， 他需要将自己注册到Zookeeper上master的Znode上。这样的目的，是当master 宕机或者新的master启动的时候，能及时收到通知。对于regionserver来说，维持和Zookeeper的联系是非常重要的。因为regionserver需要定期的将心跳包发给master server。如果regionserver不能及时的知道master的改变，就会导致regionserver和master失去联系，而成为一个僵死的进程。
于是，在默认情况下，regionserver遇到这种情况，就选择退出。
为什么regionserver 和Zookeeper的session expired? 可能的原因有
1. 网络不好。
2. Java full GC， 这会block所有的线程。如果时间比较长，也会导致session expired.
1. 将Zookeeper的timeout时间加长。
2. 配置&hbase.regionserver.restart.on.zk.expire& 为true。 这样子，遇到ZooKeeper session expired ， regionserver将选择 restart 而不是 abort
具体的配置是，在hbase-site.xml中加入
&property&
&name&zookeeper.session.timeout&/name&
&value&90000&/value&
&description&ZooKeeper session timeout.
HBase passes this to the zk quorum as suggested maximum time for a
session. &See http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions
&The client sends a requested timeout, the server responds with the
timeout that it can give the client. The current implementation
requires that the timeout be a minimum of 2 times the tickTime
(as set in the server configuration) and a maximum of 20 times
the tickTime.& Set the zk ticktime with hbase.zookeeper.property.tickTime.
In milliseconds.
&/description&
&/property&
&property&
&name&hbase.regionserver.restart.on.zk.expire&/name&
&value&true&/value&
&description&
Zookeeper session expired will force regionserver exit.
Enable this will make the regionserver restart.
&/description&
&/property&
为了避免java full GC suspend thread 对Zookeeper heartbeat的影响，我们还需要对hbase-env.sh进行配置。
export HBASE_OPTS=&$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError \
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode&
export HBASE_OPTS=&$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError \
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled \
-XX:+CMSInitiatingOccupancyFraction=70 \
-XX:+UseCMSInitiatingOccupancyOnly -XX:+UseParNewGC -Xmn256m&
更多关于Hbase performance tuning 的信息，可以参考
& 相关主题：
本文来源：网易视频云：HBase C RegionServer宕机恢复原理和应对之道_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
网易视频云：HBase C RegionServer宕机恢复原理和应对之道
基于云计算的分布式多媒体处理集群和顶级音...|
总评分0.0|
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩2页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢为什么regionserver 和Zookeeper的session expired? 可能的原因有
1.&网络不好。
2. Java full GC， 这会block所有的线程。如果时间比较长，也会导致session expired.
1. 将Zookeeper的timeout时间加长。
2. 配置“hbase.regionserver.restart.on.zk.expire” 为true。 这样子，遇到ZooKeeper session expired ， regionserver将选择 restart 而不是 abort
具体的配置是，在hbase-site.xml中加入
&property&
&name&zookeeper.session.timeout&/name&
&value&90000&/value&
&description&ZooKeeper session timeout.
HBase passes this to the zk quorum as suggested maximum time for a
session. &See http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions
“The client sends a requested timeout, the server responds with the
timeout that it can give the client. The current implementation
requires that the timeout be a minimum of 2 times the tickTime
(as set in the server configuration) and a maximum of 20 times
the tickTime.” Set the zk ticktime with hbase.zookeeper.property.tickTime.
In milliseconds.
&/description&
&/property&
&property&
&name&hbase.regionserver.restart.on.zk.expire&/name&
&value&true&/value&
&description&
Zookeeper session expired will force regionserver exit.
Enable this will make the regionserver restart.
&/description&
&/property&
为了避免java full GC suspend thread 对Zookeeper heartbeat的影响，我们还需要对hbase-env.sh进行配置。
export HBASE_OPTS=&$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError \ -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode&
export HBASE_OPTS=&$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError \ -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled&\ -XX:+CMSInitiatingOccupancyFraction=70 \ -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseParNewGC -Xmn256m&
同时，当linux的maxfile设置过小时，scan多个列族也会造成regionServer宕机
JVM配置老忘，附带mark一下
1: heap size
指定jvm的最大heap大小，如：-Xmx=2g
指定jvm的最小heap大小，如：-Xms=2g，高并发应用，建议和-Xmx一样，防止因为内存收缩/突然增大带来的性能影响。
指定jvm中New
Generation的大小，如：-Xmn256m。这个参数很影响性能，如果你的程序需要比较多的临时内存，建议设置到512M，如果用的少，尽量降低这个数值，一般来说128/256足以使用了。
d: -XX:PermSize=
指定jvm中Perm
Generation的最小值，如：-XX:PermSize=32m。这个参数需要看你的实际情况，可以通过jmap命令看看到底需要多少。
e: -XX:MaxPermSize=
Generation的最大值，如：-XX:MaxPermSize=64m
指定线程桟大小，如：-Xss128k，一般来说，webx框架下的应用需要256K。如果你的程序有大规模的递归行为，请考虑设置到512K/1M。这个需要全面的测试才能知道。不过，256K已经很大了。这个参数对性能的影响比较大的。
g: -XX:NewRatio=
指定jvm中Old
Generation heap size与New Generation的比例，在使用CMS
GC的情况下此参数失效，如：-XX:NewRatio=2
h: -XX:SurvivorRatio=
Generation中Eden Space与一个Survivor
Space的heap size比例，-XX:SurvivorRatio=8，那么在总共New
Generation为10m的情况下，Eden
i: -XX:MinHeapFreeRatio=
heap在使用率小于n的情况下，heap进行收缩，Xmx==Xms的情况下无效，如：-XX:MinHeapFreeRatio=30
j: -XX:MaxHeapFreeRatio=
heap在使用率大于n的情况下，heap&进行扩张，Xmx==Xms的情况下无效，如：-XX:MaxHeapFreeRatio=70
k: -XX:LargePageSizeInBytes=
heap的分页页面大小，&如：-XX:LargePageSizeInBytes=128m
2: garbage collector
a: -XX:+UseParallelGC
Generation使用parallel collector，并行收集，暂停，app
threads，同时启动多个垃圾回收thread，不能和CMS
gc一起使用。系统吨吐量优先，但是会有较长长时间的app pause，后台系统任务可以使用此&gc
b: -XX:ParallelGCThreads=
指定parallel
collection时启动的thread个数，默认是物理processor的个数
c: -XX:+UseParallelOldGC
Generation使用parallel collector
d: -XX:+UseParNewGC
Generation使用parallel collector，是UseParallelGC的gc的升级版本，有更好的性能或者优点，可以和CMS
gc一起使用
e: -XX:+CMSParallelRemarkEnabled
在使用UseParNewGC的情况下，尽量减少mark的时间
f: -XX:+UseConcMarkSweepGC
Generation使用concurrent cmark sweep
gc、gc thread和app
thread并行（在init-mark和remark时pause
app thread）。app pause时间较短，适合交互性强的系统，如web
g: -XX:+UseCMSCompactAtFullCollection
在使用concurrent
gc的情况下，防止memory fragmention，对live
object进行整理，使memory&碎片减少
h: -XX:CMSInitiatingOccupancyFraction=
generation&在使用了n%的比例后，启动concurrent
collector，默认值是68，如：-XX:CMSInitiatingOccupancyFraction=70
有个bug，在低版本（1.5.09
and early）的jvm上出现，
/bugdatabase/view_bug.do?bug_id=6486089
i: -XX:+UseCMSInitiatingOccupancyOnly
指示只有在old
generation在使用了初始化的比例后concurrent collector启动收集
a: -XX:MaxTenuringThreshold=
指定一个object在经历了n次young
gc后转移到old generation区，在linux64的java6下默认值是15，此参数对于throughput
collector无效，如：-XX:MaxTenuringThreshold=31
b: -XX:+DisableExplicitGC
禁止java程序中的full
gc，如System.gc()的调用。最好加上么，防止程序在代码里误用了。对性能造成冲击。
c: -XX:+UseFastAccessorMethods
get、set方法转成本地代码
d: -XX:+PrintGCDetails
打应垃圾收集的情况如：
[GC : [ParNew: 229689K-&2K), 0.0194460 secs] 1159829K-&70976K),
0.0196420 secs]
e: -XX:+PrintGCTimeStamps
打应垃圾收集的时间情况，如：
[Times: user=0.09 sys=0.00, real=0.02 secs]
f: -XX:+PrintGCApplicationStoppedTime
打应垃圾收集时，系统的停顿时间，如：
Total time for which application threads were stopped: 0.0225920 seconds
4: a web server product sample and process
JAVA_OPTS=& -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled&-XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70
最初的时候我们用UseParallelGC和UseParallelOldGC，heap开了3G，NewRatio设成1。这样的配置下young
gc发生频率约12、3秒一次，平均每次花费80ms左右，full
gc发生的频率极低，每次消耗1s左右。从所有gc消耗系统时间看，系统使用率还是满高的，但是不论是young
gc还是old gc，application
thread pause的时间比较长，不合适&web&应用。我们也调小New
Generation的，但是这样会使full gc时间加长。
后来我们就用CMS
gc（-XX:+UseConcMarkSweepGC），当时的总heap还是3g，新生代1.5g后，观察不是很理想，改为jvm
heap为2g新生代设置-Xmn1g，在这样的情况下young
gc发生的频率变成7、8秒一次，平均每次时间40-50毫秒左右，CMS
gc很少发生，每次时间在init-mark和remark（two
steps stop all app thread）总共平均花费80-90ms左右。
在这里我们曾经New
Generation调大到1400m，总共2g的jvm
heap，平均每次ygc花费时间60-70ms左右，CMS
gc的init-mark和remark之和平均在50ms左右，这里我们意识到错误的方向，或者说CMS的作用，所以进行了修改。
最后我们调小New
Generation为256m，young
gc 2、3秒发生一次，平均停顿时间在25毫秒左右，CMS
gc的init-mark和remark之和平均在50ms左右，这样使系统比较平滑，经压力测试，这个配置下系统性能是比较高的。
gc的时候他有两种触发gc的方式：gc估算触发和heap占用触发。我们的1.5.0.09&环境下有次old&区heap占用在30%左右，她就频繁gc，个人感觉系统估算触发这种方式不靠谱，还是用&heap&使用比率触发比较稳妥。
这些数据都来自64位测试机，过程中的数据都是我在jboss
log找的，当时没有记下来，可能存在一点点偏差，但不会很大，基本过程就是这样。
web server作为交互性要求较高的应用，我们应该使用Parallel+CMS，UseParNewGC这个在jdk6
-server上是默认的new generation gc，新生代不能太大，这样每次pause会短一些。CMS
mark-sweep generation可以大一些，可以根据pause
time实际情况控制。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：22375次
排名：千里之外
原创：58篇
转载：24篇
(1)(3)(3)(1)(4)(1)(5)(4)(10)(3)(13)(2)(4)(15)(1)(12)出处：/jrckkyy
HBase性能调优
我们经常看到一些文章吹嘘某产品如何如何快，如何如何强，而自己测试时却不如描述的一些数据。其实原因可能在于你还不是真正理解其内部结构，对于其性能调优方法不够了解。本文转自TaoBao的Ken Wu同学的博客，是目前看到比较完整的HBase调优文章。
原文链接：HBase性能调优
因官方Book Performance Tuning部分章节没有按配置项进行索引，不能达到快速查阅的效果。所以我以配置项驱动，重新整理了原文，并补充一些自己的理解，如有错误，欢迎指正。
zookeeper.session.timeout
默认值：3分钟（180000ms）
说明：RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.
调优：这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。
不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的（网络闪断，crash等故障，运维可快速介入），如果调低timeout时间，反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了（让其他RS根据故障机器记录的WAL日志进行恢复）。当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。特别是那些固定分配regions的场景。
hbase.regionserver.handler.count
默认值：10
说明：RegionServer的请求处理IO线程数。
调优：这个参数的调优与内存息息相关。
较少的IO线程，适用于处理单次请求内存消耗较高的Big PUT场景（大容量单次PUT或设置了较大cache的scan，均属于Big PUT）或ReigonServer的内存比较紧张的场景。
较多的IO线程，适用于单次请求内存消耗低，TPS要求非常高的场景。设置该值的时候，以监控内存为主要参考。
这里需要注意的是如果server的region数量很少，大量的请求都落在一个region上，因快速充满memstore触发flush导致的读写锁会影响全局TPS，不是IO线程数越高越好。
压测时，开启Enabling RPC-level logging，可以同时监控每次请求的内存消耗和GC的状况，最后通过多次压测结果来合理调节IO线程数。
这里是一个案例 Hadoop and HBase Optimization for Read Intensive Search Applications，作者在SSD的机器上设置IO线程数为100，仅供参考。
hbase.hregion.max.filesize
默认值：256M
说明：在当前ReigonServer上单个Reigon的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的region。
调优：小region对split和compaction友好，因为拆分region或compact小region里的storefile速度很快，内存占用低。缺点是split和compaction会很频繁。
特别是数量较多的小region不停地split, compaction，会导致集群响应时间波动很大，region数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase的bug。
一般512以下的都算小region。
大region，则不太适合经常split和compaction，因为做一次compact和split会产生较长时间的停顿，对应用的读写性能冲击非常大。此外，大region意味着较大的storefile，compaction时对内存也是一个挑战。
当然，大region也有其用武之地。如果你的应用场景中，某个时间点的访问量较低，那么在此时做compact和split，既能顺利完成split和compaction，又能保证绝大多数时间平稳的读写性能。
既然split和compaction如此影响性能，有没有办法去掉？
compaction是无法避免的，split倒是可以从自动调整为手动。
只要通过将这个参数值调大到某个很难达到的值，比如100G，就可以间接禁用自动split（RegionServer不会对未到达100G的region做split）。
再配合RegionSplitter这个工具，在需要split时，手动split。
手动split在灵活性和稳定性上比起自动split要高很多，相反，管理成本增加不多，比较推荐online实时系统使用。
内存方面，小region在设置memstore的大小值上比较灵活，大region则过大过小都不行，过大会导致flush时app的IO wait增高，过小则因store file过多影响读性能。
hbase.regionserver.global.memstore.upperLimit/lowerLimit
默认值：0.4/0.35
upperlimit说明：hbase.hregion.memstore.flush.size 这个参数的作用是 当单个memstore达到指定值时，flush该memstore。但是，一台ReigonServer可能有成百上千个memstore，每个memstore也许未达到flush.size，jvm的heap就不够用了。该参数就是为了限制memstores占用的总内存。
当ReigonServer内所有的memstore所占用的内存总和达到heap的40%时，HBase会强制block所有的更新并flush这些memstore以释放所有memstore占用的内存。
lowerLimit说明： 同upperLimit，只不过当全局memstore的内存达到35%时，它不会flush所有的memstore，它会找一些内存占用较大的memstore，做个别flush，当然更新还是会被block。lowerLimit算是一个在全局flush导致性能暴跌前的补救措施。为什么说是性能暴跌？可以想象一下，如果memstore需要在一段较长的时间内做全量flush，且这段时间内无法接受任何读写请求，对HBase集群的性能影响是很大的。
调优：这是一个Heap内存保护参数，默认值已经能适用大多数场景。它的调整一般是为了配合某些专属优化，比如读密集型应用，将读缓存开大，降低该值，腾出更多内存给其他模块使用。
这个参数会给使用者带来什么影响？
比如，10G内存，100个region，每个memstore 64M，假设每个region只有一个memstore，那么当100个memstore平均占用到50%左右时，就会达到lowerLimit的限制。假设此时，其他memstore同样有很多的写请求进来。在那些大的region未flush完，就可能又超过了upperlimit，则所有region都会被block，开始触发全局flush。
不过，除了你的内存非常小或你的应用场景里大多数都是读，我觉得不需要去调这个参数。
hfile.block.cache.size
默认值：0.2
说明：storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。
调优：当然是越大越好，如果读比写少，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认吧。设置这个值的时候，你同时要参考 hbase.regionserver.global.memstore.upperLimit ，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。
hbase.hstore.blockingStoreFiles
说明：在compaction时，如果一个Store（Coulmn Family）内有超过7个storefile需要合并，则block所有的写请求，进行flush，限制storefile数量增长过快。
调优：block写请求会影响当前region的性能，将值设为单个region可以支撑的最大store file数量会是个不错的选择，即允许comapction时，memstore继续生成storefile。最大storefile数量可通过region size/memstore size来计算。如果你将region size设为无限大，那么你需要预估一个region可能产生的最大storefile数。
hbase.hregion.memstore.block.multiplier
说明：当一个region里的memstore超过单个memstore.size两倍的大小时，block该region的所有请求，进行flush，释放内存。虽然我们设置了memstore的总大小，比如64M，但想象一下，在最后63.9M的时候，我Put了一个100M的数据，此时memstore的大小会瞬间暴涨到超过预期的memstore.size。这个参数的作用是当memstore的大小增至超过memstore.size时，block所有请求，遏制风险进一步扩大。
调优： 这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景（不包括异常）不会出现突发写或写的量可控，那么保持默认值即可。如果正常情况下，你的写请求量就会经常暴长到正常的几倍，那么你应该调大这个倍数并调整其他参数值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以预留更多内存，防止HBase server OOM。
启用LZO压缩
LZO对比Hbase默认的GZip，前者性能较高，后者压缩比较高，具体参见 Using LZO Compression。对于想提高HBase读写性能的开发者，采用LZO是比较好的选择。对于非常在乎存储空间的开发者，则建议保持默认。
不要在一张表里定义太多的Column Family
Hbase目前不能良好的处理超过包含2-3个CF的表。因为某个CF在flush发生时，它邻近的CF也会因关联效应被触发flush，最终导致系统产生更多IO。
在批量导入数据到Hbase前，你可以通过预先创建regions，来平衡数据的负载。详见 Table Creation: Pre-Creating Regions
避免CMS concurrent mode failure
HBase使用CMS GC。默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景：
当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次全jvm的stop the world（挂起所有线程），然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed，我们应该让GC在未到90%时，就触发。
通过设置 -XX:CMSInitiatingOccupancyFraction=N
这个百分比， 可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%（默认），那么你可以设置 70-80，一般高10%左右差不多。
Hbase客户端优化
将HTable的setAutoFlush设为false，可以支持客户端批量更新。即当Put填满客户端flush缓存时，才发送到服务端。默认是true。
Scan Caching
scanner一次缓存多少数据来scan（从服务端一次抓多少数据回来scan）。
默认值是 1，一次只取一条。
Scan Attribute Selection
scan时建议指定需要的Column Family，减少通信量，否则scan操作默认会返回整个row的所有数据（所有Coulmn Family）。
Close ResultScanners
通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题（对应的Server资源无法释放）。
Optimal Loading of Row Keys
当你scan一张表的时候，返回结果只需要row key（不需要CF, qualifier,values,timestaps）时，你可以在scan实例中添加一个filterList，并设置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。这样可以减少网络通信量。
Turn off WAL on Puts
当Put某些非重要数据时，你可以设置writeToWAL(false)，来进一步提高写性能。writeToWAL(false)会在Put时放弃写WAL log。风险是，当RegionServer宕机时，可能你刚才Put的那些数据会丢失，且无法恢复。
启用Bloom Filter
Bloom Filter通过空间换时间，提高读操作性能。
相关 [hbase 性能调优] 推荐：
- 学着站在巨人的肩膀上
我们经常看到一些文章吹嘘某产品如何如何快，如何如何强，而自己测试时却不如描述的一些数据. 其实原因可能在于你还不是真正理解其内部结构，对于其性能调优方法不够了解. 本文转自TaoBao的Ken Wu同学的博客，是目前看到比较完整的HBase调优文章. 原文链接：HBase性能调优. 因官方Book Performance Tuning部分章节没有按配置项进行索引，不能达到快速查阅的效果.
- 数据库 - ITeye博客
1）、hbase.regionserver.handler.count：该设置决定了处理RPC的线程数量，默认值是10，通常可以调大，比如：150，当请求内容很大（上MB，比如大的put、使用缓存的scans）的时候，如果该值设置过大则会占用过多的内存，导致频繁的GC，或者出现OutOfMemory，因此该值不是越大越好.
目前小米已经在线上开始大规模使用G1垃圾回收算法，在论坛中也看到一些朋友在讨论使用G1碰到的各种各样的问题，这里打算写一篇文章记录下调G1的一些经验．. 先传送门一下，之前在HBaseConAsia2017分享过一个g1gc调优的ppt:http://openinx.github.io//my-share/ .
- 搜索技术博客－淘宝
目前HBase已经运用于淘宝主搜索的全量和增量的数据存储，有效的减低的数据库的压力，增强了业务扩展的能力. Dump系统的特点是要求在短时间内处理大量数据，对延时要求高. 在实施这个项目过程中，我们积累了一些优化的实践，抛砖引玉，供大家参考. 环境：Hadoop CDH3U4 + HBase 0.92.1.
- 开源软件 - ITeye博客
是否对任务进行profiling，调用java内置的profile功能，打出相关性能信息. 对几个map或reduce进行profiling. 非常影响速度，建议在小数据量上尝试. 1表示不reuse，-1表示无限reuse，其他数值表示每个jvm reuse次数. reuse的时候，map结束时不会释放内存.
- CSDN博客云计算推荐文章
Hadoop为用户作业提供了多种可配置的参数，以允许用户根据作业特点调整这些参数值使作业运行效率达到最优.
对于一大批MapReduce程序，如果可以设置一个Combiner,那么对于提高作业性能是十分有帮助的. Combiner可减少Map Task中间输出的结果，从而减少各个Reduce Task的远程拷贝数据量，最终表现为Map
Task和Reduce Task执行时间缩短.
- 编程语言 - ITeye博客
1.用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用. 但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法. clone()方法不会调用任何类构造函数. 在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单.
通常我们对一个系统进行性能优化无怪乎两个步骤——性能监控和参数调整，本文主要分享的也是这两方面内容. Spark提供了一些基本的Web监控页面，对于日常监控十分有用. http://master:4040（默认端口是4040，可以通过spark.ui.port修改）可获得这些信息：（1）stages和tasks调度情况；（2）RDD大小及内存使用；（3）系统环境信息；（4）正在执行的executor信息.
关于性能优化这是一个比较大的话题，在《
由谈谈网站性能技术》中我从业务和设计上说过一些可用的技术以及那些技术的优缺点，今天，想从一些技术细节上谈谈性能优化，主要是一些代码级别的技术和方法. 本文的东西是我的一些经验和知识，并不一定全对，希望大家指正和补充. 在开始这篇文章之前，大家可以移步去看一下酷壳以前发表的《
代码优化概要》，这篇文章基本上告诉你——
要进行优化，先得找到性能瓶颈.
- 傲慢的上校的专栏
写Java也有n年了，现在还是有不少的坏的代码习惯，也通过学习别人的代码学到了不少好的习惯. 留给自己做个警戒，提示以后写代码的时候注意. 在文章的后面，会提供整理的原材料下载. 1、尽量少用new生成新对象.
用new创建类的实例时，构造雨数链中所有构造函数都会被自动调用，操作速度较慢.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。
