HBase 学习笔记---守护进程及内存调优 - 其他综合 - 红黑联盟
HBase 学习笔记---守护进程及内存调优
1、HMaster
& & & & & HMaster的任务前面已经说过了，两个大方向：一、管理Hbase Table的 DDL操作 二、region的分配工作，任务不是很艰巨，但是如果采用默认自动split region的方式， & & HMaster会稍微忙一些，负载不大，可适度对此进程做适量放大heap 的操作，但不可太大，因为更耗内存的是HRegionServer
& & &2、HRegionServer
& & & & & 这个进程是HBase中的核心守护进程，原则上是每个slave启动一个HRegionServer,但多种情况可能导致HRegionServer 意外退出，下面举几个简单的方面:
&网络不好，导致RegionServer 和 HMaster通信超时，RegionServer被认为已经挂掉，从而退出集群 --网络问题，无法从软件方面解决，关于通信超时的设置下面做个简单介绍
&Java full GC ，这个过程会block所有的线程，如果此事件过长，导致Session expired 会话过期，导致退出集群--下文会阐述
&各节点时间不一致，导致RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默认是30s，但不要太大，毕竟时间不一致是不正常现象，可将所有节点和同一服务器时间做同步，也可以和时间服务器同步。
& & & & & 第一种情况 和其它原因导致的RegionServer 超时挂掉的问题，我们要首先要调高Session的容忍度，默认180000其实这个回话有效期已经够长的了，但是有的集群是可以
& &降低了这个值，可能会造成Session 超时，这个参数是 zookeeper.session.timeout 默认18000。
& & & & & 针对上面这个参数，有的博文认为即使设为180000也不能真正的达到目的，因为zookeeper 会将minSessionTimeout 设为 2*ticktimes ,而将maxSessionTimeout 设为
& &20*ticktimes 当 zookeeper.session.timeout 设置超过20*ticktimes 的时候，系统会取 min(zookeeper.session.timeout,20*ticktimes) 来出来。
& & & & & 针对上述观点，我从中找到了结论，首先如果是分布式的Hbase那 会启动HQuorumPeer 进程 看下这个源码：
& & & & & HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ，而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。
& & & & & 调用HQuorunPeer.runZKServer
& & & & & 调用QuorumPeerMain.runFromConfig
& & & & & 设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
& & & & & 由此可看此件并没有直接和tickTime对比的机会。倒是minSessionTimeout没有设置，默认是2*ticktime
& & & & & 由此可见 其实如果设置了Zookeeper.session.timeout的话 不会轻易去截取20*ticktime，再不信可以用echo conf|nc zserver 2181 看一下 zookeeper参数
& & & & & 第二种情况是要讨论的，导致产生这个问题的主要原因是很多，产生的情景很多，比如在做 major compact的过程中，时间过长，导致Full GC等，那就尽量去减少这种情
& &况的发生。二个方面
& 适度增大守护进程的HeapSize
& 调整内存回收参数
& & & & & 第一个方面：Hbase　默认各守护进程为1G &在hbase-env.sh中有配置 export HBASE_HEAPSIZE=1000，当我们启动hbase各守护进程的时候，那所有的hbase守护进程都
& & &将是1000的heapsize，对于有的进程，够用，但有些进程取远远不够，我们可以考虑增大此参数，比如export HBASE-HEAPSIZE=6000 那就把守护进程的heap 内存调大到
& & &6G,但是这样会有问题，有些进程不需要这么多，虽然设置的比较大不影响内存的实际占用，但却混淆了对各进程内存占用的认识。所以上述参数不做改变，在下面的参数中
& & &修改守护进程Heap 内存。
export HBASE_MASTER_OPTS=&$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitatingOccupancyFraction=70&
export HBASE_REGIONSERVER_OPTS=&$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC&
& & & & & & & & & & -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70&
export HBASE_THRIFT_OPTS=&$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m&
export HBASE_ZOOKEEPER_OPTS=&$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m&
& & & & & & 我们分别对各守护进程设置堆内存 其中-Xmx 表示最大可用内存，-Xms表示出事分配内存 -Xmn 表示 年轻代堆内存分配,这个值网上有的建议按照3/3 总heapsize来设
& & &置，因为是经验值，暂无法考证合理性，更多详细的堆内存分配参数，本地不做过多阐述，后面有机会可做一个单元来解释。那其它参数是什么意思呢?
& & &-XX：+UseParNewGC 等，这就到了我们说的第二个方面：
& & & & & & 第二个方面：调整内存回收参数，比如-XX:+UseParNewGC 表示年轻带内存回收策略采用并发收集，此参数在JDK5.0已经自动配置，不需再手动配置；
& & &-XX:+UseConcMarkSweepGC 表示年老代并发收集；
& & &-XX:+CMSInitatingOccupancyFraction 表示年老代内存占用超过此比例即开始做CMS，这个参数很重要在JDK 5.0以后此值默认是90 也就是当年老代对内存占用90%以上时，
& & &才开始做内存收集，而此时剩余的10%依然接受从年轻代迁移过来的对象，迁移过快，导致年老代heap 100%时，Full GC 即开始，才是会暂停所有的任务，直至Full GC 完
& & &成，此时是造成RegionServer 意外退出的元凶，那为了安全起见，在调大堆内存的情况下 蒋此值降低到一个较低的阀值，减少Full GC的产生，那我建议此值设70%。
& & & & & 3、HQuorumPeer&
& & & & & & & &此守护集成是Zookeeper的守护进程，因为我们用的是Hbase内置的ZooKeeper 所以此进程启动过程中，会读取hbase-env.sh 所以守护进程对内存和 HBASE-HEAPSIZE
& & &的一致，所以也应在hbase-env.sh中合理设置，见HRegionServer 小节中的参数设置方法。
& & & & & 4、ThriftServerhbase如何设置region大小啊_百度知道
hbase如何设置region大小啊
我有更好的答案
regionname查询：
HBase写记录过程中regionname查找简介：主要是看如何进行region选择，完成按domain域的数据散列，分摊至不同region上 |--&HTable table = new HTable(config, tablename); |--&Put put = new Put(Bytes.toBytes(&test2&)); |--&put.add(Bytes.toBytes(cfs[j]), Bytes.toBytes(String.valueOf(1)), Bytes.toBytes(&value_3&));
|--&table.put(put);
HTable--&put()
|利用HTable管理记录 |--&doPut(Arrays.asList(put));
|--&for (Put put : puts)
|--&writeBuffer.add(put);
|--&if (n % DOPUT_WB_CHECK == 0 && currentWriteBufferSize & writeBufferSize)
|--&flushCommits();
|--&if (autoFlush || currentWriteBufferSize ...
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁HBase 学习笔记---守护进程及内存调优 - 其他综合 - 红黑联盟
HBase 学习笔记---守护进程及内存调优
1、HMaster
& & & & & HMaster的任务前面已经说过了，两个大方向：一、管理Hbase Table的 DDL操作 二、region的分配工作，任务不是很艰巨，但是如果采用默认自动split region的方式， & & HMaster会稍微忙一些，负载不大，可适度对此进程做适量放大heap 的操作，但不可太大，因为更耗内存的是HRegionServer
& & &2、HRegionServer
& & & & & 这个进程是HBase中的核心守护进程，原则上是每个slave启动一个HRegionServer,但多种情况可能导致HRegionServer 意外退出，下面举几个简单的方面:
&网络不好，导致RegionServer 和 HMaster通信超时，RegionServer被认为已经挂掉，从而退出集群 --网络问题，无法从软件方面解决，关于通信超时的设置下面做个简单介绍
&Java full GC ，这个过程会block所有的线程，如果此事件过长，导致Session expired 会话过期，导致退出集群--下文会阐述
&各节点时间不一致，导致RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默认是30s，但不要太大，毕竟时间不一致是不正常现象，可将所有节点和同一服务器时间做同步，也可以和时间服务器同步。
& & & & & 第一种情况 和其它原因导致的RegionServer 超时挂掉的问题，我们要首先要调高Session的容忍度，默认180000其实这个回话有效期已经够长的了，但是有的集群是可以
& &降低了这个值，可能会造成Session 超时，这个参数是 zookeeper.session.timeout 默认18000。
& & & & & 针对上面这个参数，有的博文认为即使设为180000也不能真正的达到目的，因为zookeeper 会将minSessionTimeout 设为 2*ticktimes ,而将maxSessionTimeout 设为
& &20*ticktimes 当 zookeeper.session.timeout 设置超过20*ticktimes 的时候，系统会取 min(zookeeper.session.timeout,20*ticktimes) 来出来。
& & & & & 针对上述观点，我从中找到了结论，首先如果是分布式的Hbase那 会启动HQuorumPeer 进程 看下这个源码：
& & & & & HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ，而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。
& & & & & 调用HQuorunPeer.runZKServer
& & & & & 调用QuorumPeerMain.runFromConfig
& & & & & 设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
& & & & & 由此可看此件并没有直接和tickTime对比的机会。倒是minSessionTimeout没有设置，默认是2*ticktime
& & & & & 由此可见 其实如果设置了Zookeeper.session.timeout的话 不会轻易去截取20*ticktime，再不信可以用echo conf|nc zserver 2181 看一下 zookeeper参数
& & & & & 第二种情况是要讨论的，导致产生这个问题的主要原因是很多，产生的情景很多，比如在做 major compact的过程中，时间过长，导致Full GC等，那就尽量去减少这种情
& &况的发生。二个方面
& 适度增大守护进程的HeapSize
& 调整内存回收参数
& & & & & 第一个方面：Hbase　默认各守护进程为1G &在hbase-env.sh中有配置 export HBASE_HEAPSIZE=1000，当我们启动hbase各守护进程的时候，那所有的hbase守护进程都
& & &将是1000的heapsize，对于有的进程，够用，但有些进程取远远不够，我们可以考虑增大此参数，比如export HBASE-HEAPSIZE=6000 那就把守护进程的heap 内存调大到
& & &6G,但是这样会有问题，有些进程不需要这么多，虽然设置的比较大不影响内存的实际占用，但却混淆了对各进程内存占用的认识。所以上述参数不做改变，在下面的参数中
& & &修改守护进程Heap 内存。
export HBASE_MASTER_OPTS=&$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitatingOccupancyFraction=70&
export HBASE_REGIONSERVER_OPTS=&$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC&
& & & & & & & & & & -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70&
export HBASE_THRIFT_OPTS=&$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m&
export HBASE_ZOOKEEPER_OPTS=&$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m&
& & & & & & 我们分别对各守护进程设置堆内存 其中-Xmx 表示最大可用内存，-Xms表示出事分配内存 -Xmn 表示 年轻代堆内存分配,这个值网上有的建议按照3/3 总heapsize来设
& & &置，因为是经验值，暂无法考证合理性，更多详细的堆内存分配参数，本地不做过多阐述，后面有机会可做一个单元来解释。那其它参数是什么意思呢?
& & &-XX：+UseParNewGC 等，这就到了我们说的第二个方面：
& & & & & & 第二个方面：调整内存回收参数，比如-XX:+UseParNewGC 表示年轻带内存回收策略采用并发收集，此参数在JDK5.0已经自动配置，不需再手动配置；
& & &-XX:+UseConcMarkSweepGC 表示年老代并发收集；
& & &-XX:+CMSInitatingOccupancyFraction 表示年老代内存占用超过此比例即开始做CMS，这个参数很重要在JDK 5.0以后此值默认是90 也就是当年老代对内存占用90%以上时，
& & &才开始做内存收集，而此时剩余的10%依然接受从年轻代迁移过来的对象，迁移过快，导致年老代heap 100%时，Full GC 即开始，才是会暂停所有的任务，直至Full GC 完
& & &成，此时是造成RegionServer 意外退出的元凶，那为了安全起见，在调大堆内存的情况下 蒋此值降低到一个较低的阀值，减少Full GC的产生，那我建议此值设70%。
& & & & & 3、HQuorumPeer&
& & & & & & & &此守护集成是Zookeeper的守护进程，因为我们用的是Hbase内置的ZooKeeper 所以此进程启动过程中，会读取hbase-env.sh 所以守护进程对内存和 HBASE-HEAPSIZE
& & &的一致，所以也应在hbase-env.sh中合理设置，见HRegionServer 小节中的参数设置方法。
& & & & & 4、ThriftServerHBase 学习笔记---守护进程及内存调优
1、HMaster
& & & & & HMaster的任务前面已经说过了，两个大方向：一、管理Hbase Table的 DDL操作 二、region的分配工作，任务不是很艰巨，但是如果采用默认自动split region的方式， & & HMaster会稍微忙一些，负载不大，可适度对此进程做适量放大heap 的操作，但不可太大，因为更耗内存的是HRegionServer
& & &2、HRegionServer
& & & & & 这个进程是HBase中的核心守护进程，原则上是每个slave启动一个HRegionServer,但多种情况可能导致HRegionServer 意外退出，下面举几个简单的方面:
&网络不好，导致RegionServer 和 HMaster通信超时，RegionServer被认为已经挂掉，从而退出集群 --网络问题，无法从软件方面解决，关于通信超时的设置下面做个简单介绍
&Java full GC ，这个过程会block所有的线程，如果此事件过长，导致Session expired 会话过期，导致退出集群--下文会阐述
&各节点时间不一致，导致RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默认是30s，但不要太大，毕竟时间不一致是不正常现象，可将所有节点和同一服务器时间做同步，也可以和时间服务器同步。
& & & & & 第一种情况 和其它原因导致的RegionServer 超时挂掉的问题，我们要首先要调高Session的容忍度，默认180000其实这个回话有效期已经够长的了，但是有的集群是可以
& &降低了这个值，可能会造成Session 超时，这个参数是 zookeeper.session.timeout 默认18000。
& & & & & 针对上面这个参数，有的博文认为即使设为180000也不能真正的达到目的，因为zookeeper 会将minSessionTimeout 设为 2*ticktimes ,而将maxSessionTimeout 设为
& &20*ticktimes 当 zookeeper.session.timeout 设置超过20*ticktimes 的时候，系统会取 min(zookeeper.session.timeout,20*ticktimes) 来出来。
& & & & & 针对上述观点，我从源码中找到了结论，首先如果是分布式的Hbase那 会启动HQuorumPeer 进程 看下这个源码：
& & & & & HQuorumPeer.main 方法中会调用 writeMyID(zkProperties) ，而就在此方法中已经将 maxSessionTimeout设置为 zookeeper.session.timeout 的时长。
& & & & & 调用HQuorunPeer.runZKServer
& & & & & 调用QuorumPeerMain.runFromConfig
& & & & & 设置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
& & & & & 由此可看此件并没有直接和tickTime对比的机会。倒是minSessionTimeout没有设置，默认是2*ticktime
& & & & & 由此可见 其实如果设置了Zookeeper.session.timeout的话 不会轻易去截取20*ticktime，再不信可以用echo conf|nc zserver 2181 看一下 zookeeper系统参数
& & & & & 第二种情况是要讨论的，导致产生这个问题的主要原因是很多，产生的情景很多，比如在做 major compact的过程中，时间过长，导致Full GC等，那就尽量去减少这种情
& &况的发生。二个方面
& 适度增大守护进程的HeapSize
& 调整内存回收参数
& & & & & 第一个方面：Hbase　默认各守护进程为1G &在hbase-env.sh中有配置 export HBASE_HEAPSIZE=1000，当我们启动hbase各守护进程的时候，那所有的hbase守护进程都
& & &将是1000的heapsize，对于有的进程，够用，但有些进程取远远不够，我们可以考虑增大此参数，比如export HBASE-HEAPSIZE=6000 那就把守护进程的heap 内存调大到
& & &6G,但是这样会有问题，有些进程不需要这么多，虽然设置的比较大不影响内存的实际占用，但却混淆了对各进程内存占用的认识。所以上述参数不做改变，在下面的参数中
& & &修改守护进程Heap 内存。
export HBASE_MASTER_OPTS=&$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitatingOccupancyFraction=70&
export HBASE_REGIONSERVER_OPTS=&$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC&
& & & & & & & & & & -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70&
export HBASE_THRIFT_OPTS=&$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m&
export HBASE_ZOOKEEPER_OPTS=&$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m&
& & & & & & 我们分别对各守护进程设置堆内存 其中-Xmx 表示最大可用内存，-Xms表示出事分配内存 -Xmn 表示 年轻代堆内存分配,这个值网上有的建议按照3/3 总heapsize来设
& & &置，因为是经验值，暂无法考证合理性，更多详细的堆内存分配参数，本地不做过多阐述，后面有机会可做一个单元来解释。那其它参数是什么意思呢?
& & &-XX：+UseParNewGC 等，这就到了我们说的第二个方面：
& & & & & & 第二个方面：调整内存回收参数，比如-XX:+UseParNewGC 表示年轻带内存回收策略采用并发收集，此参数在JDK5.0已经自动配置，不需再手动配置；
& & &-XX:+UseConcMarkSweepGC 表示年老代并发收集；
& & &-XX:+CMSInitatingOccupancyFraction 表示年老代内存占用超过此比例即开始做CMS，这个参数很重要在JDK 5.0以后此值默认是90 也就是当年老代对内存占用90%以上时，
& & &才开始做内存收集，而此时剩余的10%依然接受从年轻代迁移过来的对象，迁移过快，导致年老代heap 100%时，Full GC 即开始，才是会暂停所有的任务，直至Full GC 完
& & &成，此时是造成RegionServer 意外退出的元凶，那为了安全起见，在调大堆内存的情况下 蒋此值降低到一个较低的阀值，减少Full GC的产生，那我建议此值设70%。
& & & & & 3、HQuorumPeer&
& & & & & & & &此守护集成是Zookeeper的守护进程，因为我们用的是Hbase内置的ZooKeeper 所以此进程启动过程中，会读取hbase-env.sh 所以守护进程对内存和 HBASE-HEAPSIZE
& & &的一致，所以也应在hbase-env.sh中合理设置，见HRegionServer 小节中的参数设置方法。
& & & & & 4、ThriftServer
本文地址：/news/show-149677.html 转载请保留