默认搜索超时配置

配置项作用 #

search.default_search_timeout 配置项设置搜索请求的默认超时时间。当搜索请求中没有明确指定超时参数时，将使用此配置作为超时时间。超过此时间后，搜索请求将被取消并返回部分结果或超时错误。

配置项类型 #

该配置项为动态配置，可以在运行时通过集群设置 API 进行修改。

默认值 #

60s

是否必需 #

可选配置项（有默认值）

取值范围 #

时间格式配置（如 10s, 1m, 500ms）
-1 表示无超时限制

配置格式 #

# 默认配置
search.default_search_timeout: 60s

# 缩短超时时间
search.default_search_timeout: 30s

# 延长超时时间
search.default_search_timeout: 120s

# 无超时限制
search.default_search_timeout: -1

相关配置项 #

工作原理 #

搜索超时机制：

┌─────────────────────────────────────────────────────────────────┐
│                    搜索超时控制流程                               │
└─────────────────────────────────────────────────────────────────┘

搜索请求到达
    │
    ├── 请求中明确指定 timeout
    │   │
    │   └── 使用指定的 timeout
    │
    └── 请求中未指定 timeout
        │
        └── 使用 default_search_timeout
            │
            └── 启动超时计时器
                │
                ├── 执行搜索
                │   ├── 检查超时
                │   │
                │   ├── 未超时 → 继续
                │   │
                │   └── 已超时 → 停止执行
                │
                └── 返回结果
                    ├── 完整结果（未超时）
                    └── 部分结果（已超时）

超时处理策略 #

超时后的处理方式:

1. 允许部分结果（默认）
    GET /_search
    {
      "timeout": "10s"
    }

    超时后:
        ✓ 返回已收集的结果
        ✓ 标记为超时
        ✓ 不抛出异常
        ✓ 设置 timed_out: true

2. 不允许部分结果
    GET /_search?allow_partial_results=false
    {
      "timeout": "10s"
    }

    超时后:
        ✗ 返回失败
        ✗ 抛出异常
        ✗ 不返回部分数据

使用场景 #

1. 默认配置（推荐） #

search.default_search_timeout: 60s

适用场景：

• 大多数集群配置
• 平衡响应时间和完整性
• 一般搜索需求

2. 快速响应场景 #

search.default_search_timeout: 30s

适用场景：

• 交互式搜索
• 用户体验优先
• 防止长时间等待
• Web 界面查询

3. 复杂分析场景 #

search.default_search_timeout: 120s

适用场景：

• 复杂聚合分析
• 大数据量扫描
• 报表生成
• 批处理任务

4. 无超时限制 #

search.default_search_timeout: -1

适用场景：

• 批量导出
• 数据迁移
• 完整结果优先
• 后台任务

推荐设置建议 #

超时与性能的关系 #

超时时间对性能的影响:

短超时（10-30s）:
    优点:
        ✓ 快速释放资源
        ✓ 快速响应用户
        ✓ 防止长时间占用资源

    缺点:
        ✗ 复杂查询可能超时
        ✗ 结果不完整
        ✗ 可能需要重试

长超时（120s+）:
    优点:
        ✓ 允许复杂查询完成
        ✓ 结果更完整
        ✓ 减少重试需求

    缺点:
        ✗ 资源长时间占用
        ✗ 用户等待时间长
        ✗ 可能影响其他查询

请求级别覆盖 #

在请求中覆盖默认超时:

1. 使用默认超时
   GET /_search
   {
     "query": { "match_all": {} }
   }
   → 使用 default_search_timeout

2. 明确指定超时
   GET /_search
   {
     "timeout": "30s",
     "query": { "match_all": {} }
   }
   → 使用指定的 30s

3. URL 参数指定
   GET /_search?timeout=30s
   {
     "query": { "match_all": {} }
   }
   → 使用指定的 30s

4. 禁用超时
   GET /_search?timeout=-1
   {
     "query": { "match_all": {} }
   }
   → 无超时限制

动态配置示例 #

# 更改默认超时
PUT /_cluster/settings
{
  "transient": {
    "search.default_search_timeout": "30s"
  }
}

# 恢复默认值
PUT /_cluster/settings
{
  "transient": {
    "search.default_search_timeout": null
  }
}

# 查看当前配置
GET /_cluster/settings?filter_path=*.search.default_search_timeout

监控建议 #

# 查看当前配置
GET /_cluster/settings?filter_path=*.search.default_search_timeout

# 查看超时的查询
GET /_tasks?actions=*search&detailed=true&pretty

# 查看搜索统计
GET /_nodes/stats/indices/search

# 查看慢查询
GET /_tasks?group_by=parents&pretty

超时响应示例 #

超时后的响应:

{
  "took": 60001,
  "timed_out": true,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1000000,
    "hits": [...]
  }
}

说明:
    - took: 60001ms (超过 60s)
    - timed_out: true (已超时)
    - 返回部分结果

性能优化建议 #

优化超时设置的完整策略:

1. 根据查询类型设置
    交互式查询: 10-30s
    分析查询: 60-120s
    批处理: 无限制

2. 使用查询 profiling
    GET /_search
    {
      "profile": true,
      "query": {...}
    }
    分析查询性能

3. 优化慢查询
    - 添加索引
    - 优化过滤条件
    - 使用分页
    - 减少返回字段

4. 使用异步搜索
    POST /_search
    {
      "wait_for_completion_timeout": "10s"
    }
    允许后台执行

故障排查 #

查询频繁超时问题排查:

1. 检查默认超时配置
   GET /_cluster/settings?filter_path=*.search.default_search_timeout

2. 分析慢查询日志
   # 查看执行时间长的查询

3. 检查集群健康状态
   GET /_cluster/health

4. 检查资源使用
   GET /_nodes/stats

5. 优化查询或增加超时
   # 选择合适的方案

解决措施:
    - 优化查询性能
    - 增加默认超时时间
    - 在请求中指定更长超时
    - 使用异步搜索

注意事项 #

1. 动态更新：此配置为动态配置，可在线修改
2. 请求覆盖：可以在请求中明确指定超时覆盖默认值
3. 部分结果：超时后可能返回部分结果
4. 资源管理：合理的超时有助于资源管理
5. 用户体验：短超时提升用户响应体验
6. 业务需求：根据实际业务需求调整