诊断内存状况

● 查看各个节点的内存状况

• GET _cat/nodes?v
• GET _nodes/stats/indices?pretty
• GET _cat/nodesv&h=name,queryCacheMemory,queryCacheEvictions,requestCacheMemory,requestCacheHitCount,request_cache.miss_count
• GET _cat/nodesh=name,port,segments.memory,segments.index_writer_memory,fielddata.memory_size,query_cache.memory_size,request_cache.memory_size&v

一些常见的内存问题

● Segments 个数过多，导致 full GC

现象：集群整体响应缓慢，也没有特别多的数据读写。但是发现节点在持续进行 Full GC

分析：查看 Elasticsearch 的内存使用，发现 segments.memory 占用很大空间

解决：通过 force merge，把 segments 合并成一个。

建议：对于不在写入和更新的索引，可以将其设置成只读。同时，进行 force merge 操作。如果问题依然存在，则需要考虑扩容。此外，对索引进行 force merge ，还可以减少对 global_ordinals 数据结构的构建，减少对 fielddata cache 的开销

● Field data cache 过大，导致 full GC

现象：集群整体响应缓慢，也没有特别多的数据读写。但是发现节点在持续进行 Full GC

分析：查看 Elasticsearch 的内存使用，发现 fielddata.memory.size 占用很大空间。同时， 数据不存在写入和更新，也执行过 segments merge。

解决：将 indices.fielddata.cache.size 设小，重启节点，堆内存恢复正常

建议：Field data cache 的构建比较重，Elasticsearch 不会主动释放，所以这个值应该设置 的保守一些。如果业务上确实有所需要，可以通过增加节点，扩容解决

● 复杂的嵌套聚合，导致集群 full GC

现象：节点响应缓慢，持续进行 Full GC

分析：导出 Dump 分析。发现内存中有大量 bucket 对象，查看 日志，发现复杂的嵌套聚合

解决：优化聚合

建议：在大量数据集上进行嵌套聚合查询，需要很大的堆内存来完成。如果业务场景确实需要。 则需要增加硬件进行扩展。同时，为了避免这类查询影响整个集群，需要设置 Circuit Breaker 和 search.max_buckets 的数值