【Elasticsearch】ES内存满问题排查思路

1.概述

转载：https://bbs.huaweicloud.com/forum/thread-69710-1-1.html

2.问题排查思路

• 场景1 内存参数配置不合理。

• 场景2 查询返回的size过大。

• 场景3 深度翻页查询。

• 场景4 聚合的数据量过大、聚合的结果集太大。

• 场景5 全表扫描的查询：一次查询涉及的索引和分片数过多。

• 场景6 bulk提交的请求过大。

• 场景7 节点存在大量的segment。

3.问题排查步骤

1. 登录Manage页面，检查服务级别和实例级别的参数设置，确认其GC_OPTS参数设置为30G，且-Xms的值和-Xmx参数值相同。

2. 开启ES的慢查询日志记录。

3. 检查记录的慢查询日志，关注时间特别长的以及靠近故障时间点的日志记录。主要关注的关键字为：

场景	关键字	处理建议
查询返回的size过大	max_result_window，默认值为10000	ES适合Top N的查询，不适合做全量的查询。都需要改为scroll或search_after进行查询
深度翻页查询	{ “from”:5000， //from：定义从哪里开始拿数据 “size”:100 //size：定义一共拿多少条数据 }
聚合的数据量过大、聚合的结果集太大	aggregations + size	修改请求中返回的size的大小限制。
全表扫描的查询：一次查询涉及的索引和分片数过多	GET /_all/_search { "query": { "match_all": {} } }	建议按时间周期进行查询，查询周期较长时，进行分批查询

4. 检查thread_pool的使用，是否存在大量的bulk排队情况，和客户确认bulk请求大小，建议为5mb-16mb。

5. 检查segment的个数，以及sement占用的内存的大小，对于历史的无数据写入的索引，建议进行合并或老化。

6. 收集jmap -histio 和 heapdump进行分析。

  jmap -histo <pid>
  jmap -dump:format=b,file=/tmp/esdump.hporf <pid>