[赋能学习] ES内存满问题排查思路

问题排查思路

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

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

场景3  深度翻页查询。

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

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

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

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

问题排查步骤

  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>