共计 1471 个字符，预计需要花费 4 分钟才能阅读完成。
详情：
生产环境 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 特效。
经剖析咱们业务场景没必要缓存此查问条件，，应予以敞开。优化后的集群内存使用率状况就复原了失常状态。
点击关注，第一工夫理解华为云陈腐技术~
