转载：https://bbs.huaweicloud.com/forum/thread-69710-1-1.html
场景1 内存参数配置不合理。
场景2 查询返回的size过大。
场景3 深度翻页查询。
场景4 聚合的数据量过大、聚合的结果集太大。
场景5 全表扫描的查询：一次查询涉及的索引和分片数过多。
场景6 bulk提交的请求过大。
场景7 节点存在大量的segment。
登录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>