底层取消机制配置

配置项作用 #

search.low_level_cancellation 配置项控制是否启用搜索任务的底层取消机制。启用后，搜索任务可以更及时地响应取消请求，但可能会带来一些性能开销。

配置项类型 #

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

默认值 #

true（启用底层取消）

是否必需 #

可选配置项（有默认值）

取值范围 #

true  - 启用底层取消机制
false - 禁用底层取消机制

配置格式 #

# 默认配置（启用）
search.low_level_cancellation: true

# 禁用底层取消
search.low_level_cancellation: false

相关配置项 #

工作原理 #

底层取消机制：

┌─────────────────────────────────────────────────────────────────┐
│                    底层取消机制工作流程                           │
└─────────────────────────────────────────────────────────────────┘

搜索任务执行
    │
    ├── 定期检查取消标志
    │   │
    │   ├── low_level_cancellation: true
    │   │   │
    │   │   ├── 频繁检查取消标志
    │   │   │   - 每个文档处理后检查
    │   │   │   - 响应速度快
    │   │   │   - 轻微性能开销
    │   │   │
    │   │   └── 检测到取消请求
    │   │       │
    │   │       └── 立即停止执行
    │   │
    │   └── low_level_cancellation: false
    │       │
    │       ├── 较少检查取消标志
    │       │   - 在检查点检查
    │       │   - 响应速度慢
    │       │   - 性能开销小
    │       │
    │       └── 检测到取消请求
    │           │
    │           └── 延迟停止执行
    │
    └── 返回取消结果

取消机制对比 #

启用底层取消 (true):
    取消检查点:
        - 每个文档处理后
        - 每个分片处理后
        - 每个聚合桶处理后

    响应时间:
        - 几乎立即响应
        - 通常 < 100ms

    性能开销:
        - 轻微
        - 额外的条件判断

禁用底层取消 (false):
    取消检查点:
        - 仅在分片边界
        - 仅在聚合完成后

    响应时间:
        - 可能延迟数秒
        - 取决于执行进度

    性能开销:
        - 最小
        - 减少条件判断

使用场景 #

1. 默认配置（推荐） #

search.low_level_cancellation: true

适用场景：

• 大多数生产环境
• 需要快速取消查询
• 交互式搜索场景
• 资源需要及时释放

2. 禁用底层取消 #

search.low_level_cancellation: false

适用场景：

• 性能要求极致
• 很少取消查询
• 批处理场景
• 资源充足环境

3. 临时禁用 #

# 临时禁用以提升性能
PUT /_cluster/settings
{
  "transient": {
    "search.low_level_cancellation": false
  }
}

推荐设置建议 #

取消请求示例 #

客户端取消搜索的方式:

1. 超时自动取消
   GET /_search?timeout=5s
   {
     "query": { "match_all": {} }
   }
   → 5 秒后自动取消

2. 客户端主动取消
   → 发送搜索请求
   → 用户点击取消
   → 关闭 HTTP 连接
   → 服务端检测到连接断开
   → 取消搜索任务

3. 通过任务 API 取消
   POST /_tasks/_cancel/<task_id>
   → 明确取消指定任务

动态配置示例 #

# 禁用底层取消
PUT /_cluster/settings
{
  "transient": {
    "search.low_level_cancellation": false
  }
}

# 启用底层取消
PUT /_cluster/settings
{
  "transient": {
    "search.low_level_cancellation": true
  }
}

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

监控建议 #

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

# 查看正在执行的搜索任务
GET /_tasks?actions=*search&detailed=true&pretty

# 查看已取消的任务
GET /_tasks?actions=*search&detailed=true&pretty
# 检查 cancelled 状态

# 查看任务统计
GET /_nodes/stats/tasks?filter_path=**.cancelled

性能影响分析 #

启用底层取消的性能影响:

CPU 开销:
    - 额外的条件判断
    - 每个文档处理后检查
    - 影响: < 1% CPU

内存开销:
    - 取消标志存储
    - 影响: 可忽略

整体性能:
    - 轻微性能下降
    - 更好的资源控制
    - 更快的取消响应

权衡:
    轻微性能损失 vs
    更好的用户体验和资源控制
    大多数场景下建议启用

使用场景详解 #

1. 交互式搜索界面
    用户发起搜索后:
        - 发现查询条件错误
        - 想要重新搜索
        - 点击取消按钮

    启用底层取消:
        ✓ 立即停止执行
        ✓ 释放资源
        ✓ 允许新查询

    禁用底层取消:
        ✗ 继续执行
        ✗ 浪费资源
        ✗ 阻塞新查询

2. 长时间聚合查询
    复杂聚合查询:
        - 需要处理大量数据
        - 执行时间较长
        - 用户可能等待不耐烦

    启用底层取消:
        ✓ 用户可以中途取消
        ✓ 释放资源用于其他查询
        ✓ 提升系统响应性

3. 批量导出场景
    批量处理任务:
        - 处理大量文档
        - 不需要中途取消
        - 性能要求高

    禁用底层取消:
        ✓ 轻微性能提升
        ✓ 减少检查开销
        ✓ 更适合批处理

故障排查 #

取消操作不生效问题排查:

1. 检查配置
   GET /_cluster/settings?filter_path=*.search.low_level_cancellation

2. 检查任务状态
   GET /_tasks/<task_id>
   # 查看 running 状态

3. 检查连接状态
   # 确认客户端确实断开连接

4. 查看任务日志
   # 检查是否收到取消信号

5. 检查执行位置
   # 可能在两个检查点之间执行

常见原因:
    - 配置为 false
    - 任务在检查点之间
    - 连接未真正断开
    - 任务已经完成

注意事项 #

1. 动态更新：此配置为动态配置，可在线修改
2. 性能权衡：轻微性能开销换取更好的响应性
3. 资源控制：启用可更及时释放资源
4. 用户体验：启用可提供更好的取消响应
5. 批处理场景：可考虑禁用以提升性能
6. 默认推荐：大多数场景建议保持默认启用