1.概述
转载:https://bbs.huaweicloud.com/forum/thread-69710-1-1.html
2.问题排查思路
-
场景1 内存参数配置不合理。
-
场景2 查询返回的size过大。
-
场景3 深度翻页查询。
-
场景4 聚合的数据量过大、聚合的结果集太大。
-
场景5 全表扫描的查询:一次查询涉及的索引和分片数过多。
-
场景6 bulk提交的请求过大。
-
场景7 节点存在大量的segment。
3.问题排查步骤
-
登录Manage页面,检查服务级别和实例级别的参数设置,确认其GC_OPTS参数设置为30G,且-Xms的值和-Xmx参数值相同。
-
开启ES的慢查询日志记录。
-
检查记录的慢查询日志,关注时间特别长的以及靠近故障时间点的日志记录。主要关注的关键字为:
场景 |
关键字 |
处理建议 |
---|---|---|
查询返回的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": {} } } |
建议按时间周期进行查询,查询周期较长时,进行分批查询 |
-
检查thread_pool的使用,是否存在大量的bulk排队情况,和客户确认bulk请求大小,建议为5mb-16mb。
-
检查segment的个数,以及sement占用的内存的大小,对于历史的无数据写入的索引,建议进行合并或老化。
-
收集jmap -histio 和 heapdump进行分析。
jmap -histo <pid>
jmap -dump:format=b,file=/tmp/esdump.hporf <pid>