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

This article mainly explains the "hbase memory allocation analysis", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "hbase memory allocation analysis"!

1. Memory configuration in hbase-env.sh

There are many things that can be configured in hbase-env.sh, such as the heap size of hbase, the gc policy of hbase, and so on. In fact, it is mainly the parameters related to the size of heap and GC.

1) for heap, that is, HBASE_HEAPSIZE, the default is 1G. Configure this size, which is equivalent to the heap of all hbase daemons. There are several hbase daemons, such as HMaster, HregionServicer, thrift, and Zookeeper-related processes, in which Zookeeper should only be the zookeeper that comes with hbase, which is generally not used in the generation environment, and thrift is not used in our environment, so HBASE_HEAPSIZE is equivalent to the heap memory configured for HMaster and HregionServicer.

I read an article on the Internet that do not configure HBASE_HEAPSIZE directly, because the default is that all daemons will use memory as large as HBASE_HEAPSIZE, which is a waste of memory for HBASE_ZOOKEEPER. This makes sense, but these processes are not started in our system, so we can ignore the fact that each daemon allocates a different amount of memory for the time being.

Our current system uses export HBASE_HEAPSIZE=16384,16G memory. Where does this number come from? I believe that we have to check the official website, the official website is not omnipotent, but it is absolutely impossible not to look at the official website. Here is a passage from the official website:

Thus, ~ 20-24Gb or less memory dedicated to one RS is recommended

My English is not very good. The previous sentence probably means that regionserver cannot allocate too much memory because of GC, so I don't need to translate this sentence. 20~24GB or smaller is more appropriate. Hey. Of course, this parameter is related to many factors, and I will summarize the factors that affect this memory parameter in depth later. That's all for now.

2) GC configuration

Do not think that the configuration of the above parameters is over, because you may encounter a lot of situations. Like OOM. Why? This is about to talk about the memory mechanism of java, let's talk about it briefly, there will be a topic on JVM tuning in the future.

The figure above is a diagram of the JVM generational garbage collection system, which is briefly described:

There are three heap generations: Perm (or Permanent) [permanent], Old Generation [older], and Young [younger]. The younger generation consists of three independent spaces, Eden space and two survivor spaces, S0 and S1.

Typically, the object is allocated in the younger generation's Eden space, and if an allocation fails (Eden is full), all java threads stop and a younger generation GC (Minor GC) is called. All objects that survive in the younger generation (Eden and S0 space) are copied to S1 space. If S1 space is full, the object is copied (promoted) to the old age. When this ascension fails, the old age is collected (Major/Full GC). Permanent generations and old times are usually collected together. Permanent generations are used to store methods defined in classes and objects.

Going back to this topic, we set the parameter of GC to

Export HBASE_OPTS= "$HBASE_OPTS-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=60-XX:+UseParNewGC-XX:ParallelGCThreads=6"

A brief explanation.

-XX:+UseConcMarkSweepGC indicates that the older generation collects concurrently

For the old days, it could start recycling earlier. When the ratio of space allocated in the old era exceeded a threshold, the CMS began to run. If CMS starts too late, HBase may go straight to full garbage collection. This situation will result in all threads in block, and if this time is too long, it will cause hbase connection timeout, and the result will be regionserver collective offline. This is intolerable. To avoid this, we recommend setting the-XX:CMSInitiatingOccupancyFraction JVM parameter to specify exactly at what percentage CMS should be started, as we did in the configuration above. It is a good practice to start at 60 or 70 percent. When CMS is used in the old days, the default younger generation GC will be set to Parallel New Collector.

Let's take a look at why it is possible for hbase to carry out full gc. If we do not configure-XX:CMSInitiatingOccupancyFraction,jdk1.5 will use the default value of 90% in the future, then it is very likely that when the memory consumption of the old era exceeds 90% of the memory allocated to him, CMS will be carried out, but it will not prevent the younger generation from migrating to the old age. If the migration is too fast and the CMS is slow, there will be 100% memory utilization in the old era. This will lead to full gc. If we adjust this parameter a little smaller, then we can give the young to the old to migrate while doing CMS for some time, which will reduce the occurrence of full gc. Of course, this may be frequent gc, but it's better than the whole hbase hanging up, isn't it?

Thank you for your reading, the above is the content of "hbase memory allocation Analysis". After the study of this article, I believe you have a deeper understanding of the problem of hbase memory allocation analysis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.