Elasticsearch服务器超时问题排查与优化咨询

先聊聊你的场景：8核/16G的Qbox服务器跑单个ES节点，索引存了200万条共1.2G的数据，索引QPS最高5次/秒、搜索QPS最高1万次/秒，但中位搜索耗时已经到300ms，还出现了请求被拒绝的报错——这个情况确实得从查询、映射、ES配置几个维度一起调。

1. 先分析核心报错原因 #

你日志里的EsRejectedExecutionException是问题的关键：

org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@7ea74209 on QueueResizingEsThreadPoolExecutor[name = s-f8cb43563fe76e4a-0/search, queue capacity = 1000, min queue capacity = 1000, max queue capacity = 1000, frame size = 2000, targeted response rate = 1s, task execution EWMA = 625.6ms, adjustment amount = 50, org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor@26e28e[Running, pool size = 7, active threads = 7, queued tasks = 1000, completed tasks = 144056]]

这说明搜索线程池已被占满，任务队列也达到1000的上限，新请求直接被拒绝。本质是单个请求耗时过长（平均625ms），导致请求大量积压，服务器处理不过来。

2. 查询语句优化（最立竿见影） #

你的查询结构有点冗余，调整语法能大幅减少ES的计算量：

2.1 合并重复的Term查询 #

原来should里多个restaurant_id的term可以合并成terms查询，减少嵌套层级：

// 原写法
{
  "should": [
    {"term": {"restaurant_id": {"value": 8898}}},
    {"term": {"restaurant_id": {"value": 4164}}},
    {"term": {"restaurant_id": {"value": 4679}}}
  ]
}

// 优化后
{
  "terms": {"restaurant_id": [8898, 4164, 4679], "boost": 1.0}
}

2.2 用Filter替代Must（利用缓存） #

对于不需要打分的条件（比如state过滤、user_id/restaurant_id匹配），放到filter里，ES会自动缓存这些条件的结果，重复查询时直接复用：

{
  "bool": {
    "filter": [ // 把原must里的匹配条件移到filter
      {"terms": {"restaurant_id": [8898, 4164, 4679]}},
      {"term": {"user_id": 308612}},
      {"term": {"state": {"value": "canceled"}}},
      {"range": {"order_at": {"from": "2020-08-19T12:02:09", "to": "2020-09-19T12:02:09"}}}
    ],
    "must_not": [{"term": {"state": "created"}}],
    "should": [ // 仅保留需要打分的条件
      {"bool": {
        "should": [
          {"term": {"state": "executing"}},
          {"term": {"state": "missed"}}
        ],
        "minimum_should_match": 1
      }}
    ]
  }
}

2.3 优化排序逻辑 #

你当前用order_at升序 + created_at降序排序，这两个date字段默认已开启doc_values，但如果查询量极大，可以：

• 尝试简化排序规则（比如只按order_at排序），减少计算开销；
• 如果是滚动分页场景，用search_after替代from/size，避免每次分页都重新排序整个结果集。

2.4 保持精简返回字段 #

你已经用_source.includes指定了返回字段，这个做法很好——不要返回不需要的字段，减少数据传输和序列化的开销。

3. Mapping优化 #

你的mapping整体规范，但有几个可调整的点：

• 检查text字段必要性：customer_name_text是text类型，但当前查询未用到它做全文搜索，如果业务不需要，建议改成keyword类型或直接删除（用customer_name代替），减少索引存储和维护开销；
• 调整字段类型节省内存：比如address_id用long，但如果实际值在整数范围（小于2^31-1），可以改成integer类型；
• 关闭动态映射：当前设置dynamic: true，如果业务字段固定，建议改成dynamic: false，避免意外新增字段导致索引膨胀。

4. ES节点配置优化 #

针对8核/16G服务器，调整这些配置能显著提升性能：

• 堆内存分配：ES堆内存建议设为8G（-Xms8g -Xmx8g），不要超过物理内存的一半——剩下的内存留给Lucene做文件缓存，这部分对搜索性能至关重要；
• 搜索线程池调整：默认搜索线程池大小为CPU核心数（8核应为8，但日志显示pool size是7），可调整为thread_pool.search.size: 8；队列容量可适当调大（比如thread_pool.search.queue_size: 2000），但不要过大避免OOM；
• 开启请求缓存：在索引级别开启请求缓存，重复查询可直接复用结果：

  PUT /orders_prod-1586935194034930/_settings
  {
    "index.request_cache.enable": true
  }
  

• 调整分片数：当前索引有3个分片，建议调整为8个（和CPU核心数一致），让每个分片利用一个核心，提升并行处理能力（注意：分片数需创建索引时设置，或通过reindex调整）。

5. 服务器层面优化 #

• 磁盘IO检查：ES对磁盘IO敏感，如果用的是机械硬盘，建议换成SSD——机械硬盘随机IO性能差，会严重拖慢搜索速度。可用iostat查看磁盘读写负载，若%util经常超过80%，说明磁盘是瓶颈；
• CPU使用率监控：用top或htop查看CPU使用率，若经常跑满，说明查询太复杂或线程池不足，结合前面的查询优化和线程池调整解决。

内容的提问来源于stack exchange，提问作者silviu.rosu