Elasticsearch:fielddata内存使用陡增解决方案

一、问题描述

        观察7天的集群监控-高级监控-fielddata内存使用，发现在8/23日有飙升的情况，而且最近指标也没有下来，针对于当前情况提出以下三个问题：

1)为什么会造成这里的指标飙升？

2)如何才能将指标降下来？

3)fielddata内存使用这个指标是不是直接影响HeapMemory使用率？

二、解决方案与处理过程

1）为何会造成指标飙升

通过以下命令判断一下是什么字段导致的fielddata突增：

# 显示每个节点字段所占的堆空间 并按照所占空间降序排列
GET _cat/fielddata?v&s=size:desc  

        当前命令执行,返回如下图所示（敏感信息已隐藏）：可以看到这些节点上的size之和与fielddata内存使用指标上的值保持一致。

        除了定位什么字段导致，也需要定位到具体是哪个索引，来方便针对性的清理缓存或者定位具体查询语句。可以通过以下命令按照fielddata的占用大小倒序确认一下是哪个索引导致的： 

# indices:查看集群中所有index的详细信息
GET _cat/indices?v&h=index,fielddata.memory_size&s=fielddata.memory_size:desc 

        同样是将命令执行在集群,返回如下图所示(敏感信息已隐藏)：可以看到fielddata内存占用最多的是****_2207的索引，其次是****_2208的索引。

        根据前面排查的问题索引及字段，在对应时间点的慢日志中，具体找出问题的查询语句。例如：_id 的大量占用，手动开启 （"fielddata":true） 并对text字段进行排序聚合类操作等。

2)如何降指标

        可以直接去针对该索引清理缓存（可能导致该索引的查询变慢，引起业务抖动，提前和客户说明风险）。执行下列语句：

POST /索引名/_cache/clear?fielddata=true  

        或者直接对所有索引都清理 ：

POST /_cache/clear?fielddata=true 

3）fielddata内存使用这个指标是不是直接影响HeapMemory使用率？

        是有影响的，因为fielddata不是临时缓存，它是驻留在内存里的数据结构，必须可以快速执行访问，构建它的代价也比较高昂。垃圾回收是不会回收这部分缓存的，清理掉缓存需要告知客户应避免对text类型字段、_id 字段进行排序聚合。

三、思考

        对于“fielddata内存使用指标陡增”这种情况，会直接导致集群的内存使用率上升，一旦内存使用率超过90%即会对集群的性能产生影响，直接结果是索引的写入与查询效率降低。所以需要防患于未然，在达到报警水位线之前将“对text类型字段、_id 字段进行排序聚合”的业务进行修改或使用其它方案替代，保证集群的稳定性。