28-一些常见的内存问题
诊断内存状况
● 查看各个节点的内存状况
- 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 的数值
原文地址:https://blog.csdn.net/zhouweiye2012/article/details/143799761
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!