Shulou(Shulou.com)05/31 Report--

This article is about how hbase implements daemons and memory tuning. Xiaobian thinks it is quite practical, so share it with everyone for reference. Let's follow Xiaobian and have a look.

1、HMaster

HMaster's task has been mentioned above, two major directions: 1. Manage DDL operations of Hbase Table 2. Assign region work. The task is not very difficult, but if the default automatic split region method is adopted, HMaster will be slightly busy. The load is not large. You can appropriately enlarge the heap operation for this process, but it should not be too large, because HRegionServer consumes more memory.

2、HRegionServer

This process is the core daemon in HBase. In principle, each slave starts an HRegionServer, but many situations may cause HRegionServer to quit unexpectedly. Here are a few simple aspects:

Poor network, resulting in communication timeout between RegionServer and HMaster. RegionServer is considered to have been suspended, thus exiting the cluster--Network problem, which cannot be solved from the software side. The following is a brief introduction to the setting of communication timeout

Java full GC, this process blocks all threads, if this event is too long, causes the Session expired session to expire, causing the cluster to exit--explained below

The time of each node is inconsistent, causing RegionServer to exit. -- hbase.master.maxclockskew Increase tolerance, default is 30s, but not too large, after all, time inconsistency is abnormal, you can synchronize all nodes with the same server time, you can also synchronize with the time server.

The first case and other reasons caused by RegionServer timeout hang problem, we must first increase the Session tolerance, default 180000 In fact, this reply validity period is long enough, but some clusters can be

Lowering this value may cause a Session timeout. This parameter is zookeeper.session.timeout. Default 18000.

For the above parameter, some blog posts think that even if it is set to 180000, it will not really achieve the goal, because zookeeper will set minSessionTimeout to 2*ticktimes , and maxSessionTimeout to

20*ticktimes When zookeeper.session.timeout is set to more than 20*ticktimes, min(zookeeper. session. timeout, 20 *ticktimes) is taken.

For the above point of view, I found the conclusion from the source code, first of all, if it is distributed Hbase, it will start the HQuorumPeer process. Look at this source code:

WriteMyID(zkProperties) is called in the HQuorumPeer.main method, where maxSessionTimeout is set to the duration of zookeeper.session.timeout.

Call HQuorunPeer.runZKServer

Call QuorumPeerMain.runFromConfig

Set quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());

It can be seen that this article does not have a direct chance to compare with tickTime. minSessionTimeout is not set, default is 2*ticktime

It can be seen that if Zookeeper.session.timeout is set, it will not easily intercept 20*ticktime. If you don't believe it, you can use echo conf.| nc zserver 2181 Take a look at zookeeper system parameters

The second situation is to be discussed. The main reasons for this problem are many. There are many scenarios. For example, in the process of doing major compact, the time is too long, resulting in Full GC, etc., so try to reduce this situation as much as possible.

The situation occurs. second aspect

Moderately increase the daemon HeapSize

Adjust memory reclamation parameters

The first aspect: Hbase defaults to 1G daemons. There is a configuration export HBASE_HEAPSIZE=1000 in hbase-env.sh. When we start the daemons of hbase, all the daemons of hbase are

The heapsize will be 1000, which is enough for some processes, but some processes are far from enough. We can consider increasing this parameter, such as export HBASE-HEAPSIZE=6000, and then increase the heap memory of the daemon process to

6G, but this will have problems, some processes do not need so much, although the setting is relatively large does not affect the actual memory occupation, but it confuses the understanding of the memory occupation of each process. So the above parameters do not change, in the following parameters

Modify daemon Heap memory.

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=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"

We set the heap memory for each daemon separately, where-Xmx represents the maximum available memory, -Xms represents the accident allocation memory-Xmn represents the young generation heap memory allocation, this value is recommended on the Internet according to 3/3 total heapsize to set

Set, because it is an empirical value, temporarily unable to verify the rationality, more detailed heap memory allocation parameters, local do not elaborate too much, there is a chance to do a unit to explain later. What do the other parameters mean?

-XX: +UseParNewGC, etc., which brings us to the second aspect:

The second aspect: adjust the memory reclamation parameter, such as-XX:+UseParNewGC indicates that the young band memory reclamation policy adopts concurrent collection, this parameter has been automatically configured in JDK5.0, and no manual configuration is required;

-XX:+ UseConcepMarkSweepGC indicates concurrent collection of older generations;

-XX:+CMSInitiatingOccupancyFraction indicates that CMS will be started when the memory occupation of the old generation exceeds this proportion. This parameter is very important. After JDK 5.0, this value defaults to 90, that is, when the memory occupation of the old generation exceeds 90%,

Only when the memory collection is started, and the remaining 10% still accept objects migrated from the younger generation, the migration is too fast, resulting in the old generation heap 100%, Full GC will start, and then all tasks will be suspended until Full GC is finished.

At this time, it is the culprit that causes RegionServer to quit unexpectedly. For safety reasons, reduce this value to a lower threshold in the case of adjusting a large amount of memory to reduce the generation of Full GC. Then I suggest setting this value to 70%.

3、HQuorumPeer

This daemon integration is the Zookeeper daemon, because we are using Hbase built-in ZooKeeper, so this process starts up, it reads hbase-env.sh, so the daemon is on memory and HBASE-HEAPSIZE.

Therefore, it should also be set reasonably in hbase-env.sh. See parameter setting method in HRegionServer section.

4、ThriftServer

ibid.

Thank you for reading! About "hbase how to achieve daemon and memory tuning" this article is shared here, I hope the above content can be of some help to everyone, so that everyone can learn more knowledge, if you think the article is good, you can share it to let more people see it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.