详情：

生产环境HBase集群内存常常处于高位（90%），而且GC之后也是内存仍然处于高位，经剖析内存全副由集群的regionserver过程所持有，，常常重启之后，大略3-4天就会放弃在高位。由上述症状，能够判断集群内存有泄露的嫌疑。

剖析

1、先相熟一下HBase的内存模型

HBase零碎中有两块大的内存治理模块，一块是MemStore ，一块是BlockCache，前置是用于集群写入所属内存，而后者用于缓存热数据，提供查问速度。这两者均能够通过配置文件进行配置。以后集群均配置了0.4和0.4的比例。而思考到HBase集群是多写少读的情景，为此而引入了MSLAB机制来优化HBase的MemStore 累赘。内存的使用率会出现很柔美的锯齿图形。

2、剖析内存使用率和业务关系

起初认为是读写业务量曾经超过了集群负载能力，但集群业务也不大，写和读的TPS，带宽吞吐量均未达到集群限定的能力，而且CPU利用率大多半都被GC占用，但内存就是持高不下，即便业务了停了一天，内存还是不怎么降落，很显著和业务量无关。

那么和compaction无关？经察看确实能够看compact时特地耗费工夫。此时感觉看到了心愿，调整各个参数，把compact操作晋升了10+倍之后，内存还是持高不下 。剩下最根治的方法就是剖析内存，看一下内存数据都是什么？有无内存泄露问题。

3、剖析dunp文件

节点dump下regionserver的内存，剖析发现内存中有50个RpcServer.FifoRWQ.default.read.handler线程，每个线程持有了1.2%左右的总内存，那么所有的线程持有的内存占有量大于为50*1.2%=60%。随着查问次数增多，线程继续的内存还会继续减少，如下图。

剖析每一个线程持有的内存数据，全部都是业务信息。

那么持续剖析，此业务信息所属对象：org.locationtech.geomesa.filter.factory.FastFilterFactory。而比照同规模的集群，确实是此异样集群开启了GeoMesa个性。找到问题所在，那就看源码剖析是惟一前途。

解决方案

经剖析GeoMesa源码，缓存数据为GeoMesa的filterCache，全部都是查问的条件及其优化后查问条件。如下代码：

override def getOrElseUpdate(key: K, op: => V): V = { val cached = caches.get.getIfPresent(key) if (cached != null) { cached } else { val value = op
//value=optimize(sft, ECQL.toFilter(ecql))
caches.get.put(key, value)     value   } }

导致集群随着查问次数增多，内存始终继续不下。

是否去掉此处缓存策略呢？为什么缓存此查问信息呢，目标就是为了缩小同样的查问再次被优化的步骤。那么咱们查问添条件key有没有重复使用，此处有个严格规定，就是key中不仅保障应用雷同的GeoMesa函数还有应用雷同的参数，基于这个准则，业务上查问条件是没有反复的。

咱们配置了可选参数useFilterCache，默认是开启的，没必要缓存此查问条件，应予以删除。

论断

在配置文件中增加了useFilterCache参数，默认是开启的，依据业务须要抉择开始和敞开filterCache特效。

经剖析咱们业务场景没必要缓存此查问条件，，应予以敞开。优化后的集群内存使用率状况就复原了失常状态。

点击关注，第一工夫理解华为云陈腐技术~