Hbase读写缓存优化

       我们在hbase使用过程，经常遇到hbase慢问题，我们在生产中也是遇到这个，尤其是大量业务袭来的时候，数据量一上来，hbase读写慢问题非常明显。很多时候，是通过日志和监控观察某个节点压力大，重启对应的region server，这样可以短时解决hbase慢过程中region server服务夯死的问题，但是重启后，本地化率降低，查询还是变慢，出现了夯死、重启、本地化率低的死循环。于是我们分析hbase读写缓存情况，发现有可以改善的地方。

首先我们调整了datanode的jvm，

S0C：年轻代中第一个survivor（幸存区）的容量 (K)   S1C：年轻代中第二个survivor（幸存区）的容量 (K)  S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (k)  S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (k)  EC：年轻代中Eden（伊甸园）的容量 (k)  EU：年轻代中Eden（伊甸园）目前已使用空间 (k)  OC：Old代的容量 (k)  OU：Old代目前已使用空间 (k)

       可以看出，old使用了近9个G。

       我们以日志中的ResponseTooSlow作为慢日志数量的参考，捞取了全集群的各节点的region server的慢日志。

 

       在调查过程中，发现有个别主机swap开起来了，关闭个别主机的swap，分析hbase慢日志， swap关闭前慢日志一天出现3200次，关闭后一天出现1900次，有明显的降低，但是还是会有集群整体慢的情况。

继续分析日志，

 

        目前堆外bucketCache占用27G，经查42台主机最多只占用了6.1G，可以将regionServer的读缓存由30G缩减至10G。目前dn进程最多占了22G，按目前CMSGC是触发阀值是70%，即要达到23G才会触发CMSGC回收。按互联网公司的dataNode的内存分配设置，dataNode不需要太大的内存，所以可以将datanode的参数可以进行修改，把CMS由87改为70

       我们在集群中选了两台主机进行测试，对region server的读缓存进行修改参数，将原来给region server读缓存分配的32G改成5G（hbase.bucketcache.size）
 

      修改完这些参数后，datanode的gc情况有所改善。

      我们在调查日志和配置文件中发现，

比如：2020-05-21 01:05:36,197 INFO  [LruBlockCacheStatsExecutor] hfile.LruBlockCache: totalSize=1.85 GB, freeSize=10.70 GB, max=12.54 GB, blockCount=16817,accesses=21089472365,hits=21089472365, hitRatio=100.00%,,cachingAccesses=21089405055, cachingHits=21089405055,cachingHitsRatio=100.00%,evictions=227477, evicted=81657, evictedPerRun=0.35896816849708557

       可以看出LruBlockCache分配给的最大12.54G，但是使用的才1.85G，有点浪费空间，可以将这个资源释放出来给系统。

       根据hmaster上的信息，我们将读写缓存做如下调整，
 

<property>       <name>hbase.regionserver.global.memstore.size</name>       <value>0.4</value> </property> <property>       <name>hfile.block.cache.size</name>       <value>0.4</value> </property> 改造后 <property>       <name>hbase.regionserver.global.memstore.size</name>       <value>0.6</value> </property> <property>       <name>hfile.block.cache.size</name>       <value>0.2</value> </property>

修改参数之后，我们观察iostat和vmstat

可以看出，压力并不是很大。
根据研发提供的准确数据如下，
dn内存缩减情况：32G降为5G，不影响应用。

说明：jstat了10个小时，CMSGC了5次，总耗时0.145秒，老年代增长缓慢，CMSGC后谷值599M，说明dn不怎么吃内存。

regionServer读写缓存比例调整情况：调整后CMSGC总耗时变长，写缓存要恢复为0.4，读缓存不变。

A、B改完后对比C、D

比较	CMSGC次数	耗时（分钟）	老年代内存谷底值（百分比）	老年代内存峰顶值（百分比）
调整后A	5505	7.161	0.68	0.73
调整后B	6706	9.28	0.67	0.74
不变C	46	0.20	0.40	0.68
不变D	22	0.12	0.32	0.64

 

主机慢志情况分析：

比较	IP	主机名	慢日志出现次数
调整后A	134.A.A.A	A.dcs.com	2076
调整后B	134.B.B.B	B.dcs.com	940
不变C	134.C.C.C	C.dcs.com	13648
不变D	134.D.D.D	D.dcs.com	1983

 

        修改参数的集群，配置不一样，存在256和128G的不同主机内存，鉴于所在集群的业务不同，取五台256G内存的主机，将热表的region迁移至这五台主机上region server下，并将region server的内存使用由32G扩至42G，降低个别表对集群压力的同时，释放主机里更多内存用于服务。后期我们发现读缓存还是给的太多，可以将读缓存由前面的0.2改为0.1，写缓存保持不变，继续分配0.4。修改完参数后，需要重启datanode和region server服务，所以需要对表做major_compact，提升本地化率。下面是调整参数后，几个比较显著的数据。