--- title: "作业调度器请求超时配置" date: 2026-01-16 lastmod: 2026-01-16 description: "jobscheduler.request_timeout 配置项用于控制作业调度器执行搜索请求的超时时间。" tags: ["作业调度", "超时控制", "请求管理", "性能优化"] summary: "配置项作用 # jobscheduler.request_timeout 配置项用于控制作业调度器在进行搜索请求时的超时时间。 此配置主要影响 Job Sweeper(作业清理器)执行搜索操作时的超时控制,确保在集群负载高或网络延迟的情况下,搜索请求能够在合理时间内完成或超时。 配置项属性 # 配置路径: jobscheduler.request_timeout 数据类型: TimeValue(时间值) 默认值: 10s(10秒) 最小值: 必须为正数(大于0) 是否可选: 是 作用域: NodeScope(节点级别) 动态更新: 是(支持动态更新) 配置项详解 # 工作机制 # 请求超时处理流程 正常完成: 请求 ──→ 搜索 ──→ 响应 │ │ └── 10s 内 ────┘ ✅ 超时处理: 请求 ──→ 搜索 ──→ ... ──→ 超时 │ │ └── 超过 10s ──┘ ❌ │ ↓ 抛出异常 │ ↓ 触发重试 在 Job Sweeper 中的应用 # Job Sweeper 搜索流程 1." --- ## 配置项作用 `jobscheduler.request_timeout` 配置项用于控制**作业调度器在进行搜索请求时的超时时间**。 此配置主要影响 Job Sweeper(作业清理器)执行搜索操作时的超时控制,确保在集群负载高或网络延迟的情况下,搜索请求能够在合理时间内完成或超时。 ## 配置项属性 - **配置路径**: `jobscheduler.request_timeout` - **数据类型**: `TimeValue`(时间值) - **默认值**: `10s`(10秒) - **最小值**: 必须为正数(大于0) - **是否可选**: 是 - **作用域**: NodeScope(节点级别) - **动态更新**: 是(支持动态更新) ## 配置项详解 ## 工作机制 ``` 请求超时处理流程 正常完成: 请求 ──→ 搜索 ──→ 响应 │ │ └── 10s 内 ────┘ ✅ 超时处理: 请求 ──→ 搜索 ──→ ... ──→ 超时 │ │ └── 超过 10s ──┘ ❌ │ ↓ 抛出异常 │ ↓ 触发重试 ``` ## 在 Job Sweeper 中的应用 ``` Job Sweeper 搜索流程 1. 创建搜索请求 │ ↓ 2. 设置超时时间 (request_timeout) │ ↓ 3. 执行搜索 (使用重试策略) │ ├──── 成功 ──→ 处理结果 ✅ │ └──── 超时 ──→ 重试 ⏸ │ ↓ retry_count 次 │ ├──── 成功 ──→ 处理结果 ✅ │ └──── 失败 ──→ 记录错误 ❌ ``` ## 全量扫描超时控制 ``` sweepSearchTimeout 的使用 全量扫描任务: ├── 分页获取所有作业 ├── 每页执行搜索查询 ├── 每次搜索使用 sweepSearchTimeout └── 确保单次搜索不会无限等待 搜索超时: GET /.jobscheduler-*/_search timeout: 10s │ ↓ 搜索执行... │ ├──── 10s 内返回 ──→ 成功 ✅ │ └──── 超过 10s ──→ 超时异常 ❌ ``` ## 配置建议 ## 生产环境(默认) ```yaml jobscheduler: request_timeout: 10s # 默认值 ``` **建议**: 保持默认值 `10s`。适用于大多数场景。 ## 大规模集群 ```yaml jobscheduler: request_timeout: 30s # 增加超时时间 ``` **建议**: 增加到 `30s`。集群规模大、数据量多时使用。 ## 高延迟网络 ```yaml jobscheduler: request_timeout: 60s # 进一步增加 ``` **建议**: 设置为 `60s`。网络延迟较高时使用。 ## 快速响应场景 ```yaml jobscheduler: request_timeout: 5s # 减少超时时间 ``` **建议**: 减少到 `5s`。需要快速失败时使用。 ## 代码示例 ## easysearch.yml 基础配置 ```yaml jobscheduler: request_timeout: 10s ``` ## 大规模集群配置 ```yaml jobscheduler: request_timeout: 30s sweeper: period: 10m page_size: 200 ``` ## 高延迟网络配置 ```yaml jobscheduler: request_timeout: 60s retry_count: 5 sweeper: backoff_millis: 100 ``` ## 动态更新配置 ```json PUT /_cluster/settings { "transient": { "jobscheduler.request_timeout": "30s" } } ``` ## 相关配置 | 配置项 | 作用 | 默认值 | |--------|------|--------| | `jobscheduler.request_timeout` | 请求超时时间 | 10s | | `jobscheduler.retry_count` | 重试次数 | 3 | | `jobscheduler.sweeper.backoff_millis` | 退避延迟时间 | 50ms | | `jobscheduler.sweeper.period` | 清理周期 | 5m | ## 性能影响分析 | request_timeout 设置 | 优点 | 缺点 | |----------------------|------|------| | 5s | 快速失败 | 可能误判正常慢查询 | | 10s(默认) | 平衡响应和超时 | 标准设置 | | 30s | 容忍慢查询 | 故障检测延迟 | | 60s | 最大容忍 | 故障检测很慢 | ## 超时时间与重试的关系 ``` 总执行时间估算 假设 request_timeout = 10s,retry_count = 3 第 1 次尝试: ├── 正常响应: 2s ✅ └── 总时间: 2s 第 1 次超时: ├── 等待超时: 10s ❌ ├── 退避延迟: ~60ms ├── 第 2 次尝试: 10s ❌ ├── 退避延迟: ~100ms ├── 第 3 次尝试: 10s ❌ ├── 退避延迟: ~150ms ├── 第 4 次尝试: 10s ❌ └── 总时间: ~30.3s ``` ## 使用场景 ## 推荐使用默认值的场景 - **标准集群**: 集群规模适中,网络良好 - **正常负载**: 集群负载在正常范围内 - **标准响应**: 搜索请求响应时间正常 ## 推荐增加超时的场景 - **大规模集群**: 节点多、数据量大 - **高负载**: 集群经常处于高负载状态 - **高延迟**: 网络延迟较高 - **复杂查询**: 搜索查询较为复杂 ## 推荐减少超时的场景 - **快速故障检测**: 需要快速发现故障 - **低延迟要求**: 对延迟敏感 - **网络良好**: 网络质量很好 ## 与重试配置的配合 ``` 超时和重试的协同工作 配置示例: request_timeout: 10s retry_count: 3 backoff_millis: 50ms 执行流程: 尝试 1: 0s ───────────────────── 10s (超时) ↓ 等待 50ms 尝试 2: 10.05s ─────────────────── 20.05s (超时) ↓ 等待 ~100ms 尝试 3: 20.15s ─────────────────── 30.15s (超时) ↓ 等待 ~150ms 尝试 4: 30.30s ─────────────────── 40.30s (超时) ↓ 最终失败 总耗时 ≈ 40.3 秒 ``` ## 注意事项 1. **默认值**: 默认值为 `10s`,适用于大多数场景。 2. **时间格式**: 支持 `10s`、`500ms`、`1m` 等时间格式。 3. **动态更新**: 支持动态更新,修改后立即生效。 4. **与重试配合**: 应与 `retry_count` 和 `backoff_millis` 配合配置。 5. **集群规模**: 大规模集群应适当增加超时时间。 6. **网络条件**: 网络延迟高时应增加超时时间。 7. **故障检测**: 超时时间越长,故障检测越慢。 8. **资源占用**: 超时的请求会占用资源直到超时。 9. **监控建议**: 监控搜索请求的响应时间,评估超时设置。 10. **测试验证**: 配置变更后应验证作业调度是否正常。 ## 废弃说明 此配置项在 `LegacyOpenDistroJobSchedulerSettings` 中已被标记为废弃(Deprecated)。建议使用新的 `JobSchedulerSettings` 中的配置。