异步搜索通用线程池保活时间配置

配置项作用 #

thread_pool.async_search_generic.keep_alive 配置项用于控制异步搜索通用线程池中弹性线程的保活时间。

当线程数超过核心线程数（core）时，空闲的弹性线程在指定时间后会被回收，释放系统资源。

配置项属性 #

• 配置路径: thread_pool.async_search_generic.keep_alive
• 数据类型: TimeValue（时间值）
• 默认值: 30m（30 分钟）
• 是否可选: 是
• 作用域: NodeScope（节点级别）
• 动态更新: 否（需要重启节点生效）

配置项详解 #

工作机制 #

弹性线程生命周期

SCALING 线程池:

核心线程 (core):
├── 数量: 固定
├── 创建: 启动时
├── 回收: 永不 ✅
└-- 始终保持活跃


弹性线程 (core 到 max):
├── 创建: 任务增加时
├── 用途: 应对负载波动
├── 空闲: 等待新任务
└-- 空闲超过 keep_alive → 回收


生命周期:

1. 创建阶段
   负载增加
       ↓
   活跃线程 = core
       ↓
   仍有任务在队列
       ↓
   创建新线程 (core + 1, core + 2, ...)
       ↓
   线程开始执行任务


2. 活跃阶段
   线程执行任务
       ↓
   完成当前任务
       ↓
   获取下一个任务
       ↓
   继续执行


3. 空闲阶段
   无新任务
       ↓
   线程进入空闲
       ↓
   等待新任务
       ↓
   计时器启动 ⏱️


4. 回收判断
   空闲时间 < keep_alive?
   ├── 是 → 继续等待
   └── 否 → 回收线程


5. 回收阶段
   线程被终止
       ↓
   释放资源
       ↓
   线程数减少

keep_alive 时间影响 #

不同 keep_alive 值的影响

keep_alive = 1m (短):

优点:
├── 资源释放快 ✅
├── 内存占用低 ✅
└-- 节省系统资源


缺点:
├── 频繁创建/销毁 ⚠️
├── 突发响应慢 ⚠️
└-- CPU 开销增加


适用:
├── 负载波动大
├── 资源紧张
└-- 成本敏感


keep_alive = 30m (默认):

优点:
├── 平衡性能和资源 ✅
├── 减少创建开销 ✅
├── 应对间歇负载 ✅
└-- 适用大多数场景


缺点:
├── 空闲时占用资源
└-- 响应稍慢于更长配置


适用:
├── 标准生产环境 ✅
├-- 一般负载模式
└-- 推荐配置 ✅


keep_alive = 60m (长):

优点:
├── 快速响应突发 ✅
├── 减少创建开销 ✅
└-- 性能最优


缺点:
├── 资源占用时间长 ⚠️
├── 内存占用高 ⚠️
└-- 浪费资源


适用:
├── 突发负载频繁
├── 资源充足
└-- 性能优先

负载场景分析 #

负载模式与 keep_alive

场景 1: 平稳负载
├── 特点: 负载稳定
├── 线程: 始终在 core
├── keep_alive: 影响小
└-- 推荐: 默认即可


场景 2: 间歇性负载
├── 特点: 周期性高峰
├── 线程: 波动
├── keep_alive: 重要
│   ├── 短: 频繁创建
│   ├── 长: 保持线程
│   └-- 中等: 平衡
└-- 推荐: 15-30m


场景 3: 突发负载
├── 特点: 偶尔高峰
├-- 线程: 突然增加
├── keep_alive: 关键
│   ├── 短: 响应慢
│   ├── 长: 快速响应
│   └-- 根据突发频率
└-- 推荐: 30-60m


场景 4: 持续高负载
├── 特点: 始终高负载
├── 线程: 接近 max
├── keep_alive: 影响小
└-- 推荐: 默认即可

资源占用分析 #

资源占用估算

假设:
├── core: 2
├── max: 32
├-- 弹性线程: 30


单个线程资源:
├── 栈内存: ~1MB
├── 堆内存: ~0.5MB
└── 单线程总计: ~1.5MB


keep_alive = 1m:
├── 高峰后 1 分钟回收
├── 资源释放: 快
├── 平均占用: 较低
└-- 节省资源 ✅


keep_alive = 30m (默认):
├── 高峰后 30 分钟回收
├── 资源释放: 中等
├── 平均占用: 中等
├── 弹性线程占用: 30 × 1.5MB = 45MB
└-- 平衡配置 ✅


keep_alive = 60m:
├── 高峰后 60 分钟回收
├── 资源释放: 慢
├-- 平均占用: 较高
├-- 弹性线程占用: 30 × 1.5MB = 45MB (持续)
└-- 资源浪费 ⚠️


建议: 根据负载模式选择

配置建议 #

默认配置（推荐） #

thread_pool:
  async_search_generic:
    keep_alive: 30m  # 默认值

建议: 大多数场景使用默认值。

快速回收配置 #

thread_pool:
  async_search_generic:
    keep_alive: 5m  # 快速回收

建议: 资源受限或负载波动大的场景。

长保活配置 #

thread_pool:
  async_search_generic:
    keep_alive: 60m  # 长时间保活

建议: 突发负载频繁的场景。

极速回收配置 #

thread_pool:
  async_search_generic:
    keep_alive: 1m  # 极速回收

建议: 成本敏感或资源极度受限。

代码示例 #

基础配置 #

thread_pool:
  async_search_generic:
    keep_alive: 30m

时间值格式 #

thread_pool:
  async_search_generic:
    keep_alive: 30m   # 分钟
    # 或
    keep_alive: 1800s # 秒
    # 或
    keep_alive: 0.5h  # 小时

完整异步搜索线程池配置 #

thread_pool:
  async_search_generic:
    core: 2
    max: 32
    keep_alive: 30m

资源优化配置 #

thread_pool:
  async_search_generic:
    core: 1
    max: 16
    keep_alive: 5m

高性能配置 #

thread_pool:
  async_search_generic:
    core: 4
    max: 64
    keep_alive: 60m

相关配置 #

注意事项 #

1. 默认值: 默认值为 30m，适用于大多数场景。

2. 非动态更新: 需要重启节点才能生效。

3. 资源权衡: 较短的值节省资源，较长的值提高性能。

4. 负载模式: 根据实际负载模式选择合适的值。

5. 弹性线程: 只影响超过 core 的弹性线程。

6. 创建开销: 较短的值会增加线程创建开销。

7. 突发响应: 较长的值能更快响应突发负载。

8. 内存占用: 弹性线程会占用内存直到回收。

9. 监控建议: 监控活跃线程数和资源使用。

10. 测试验证: 调整后应观察负载模式效果。

使用场景 #

场景选择指南

标准生产环境:
├── keep_alive: 30m
├── 特点: 负载相对稳定
├── 资源: 充足
└-- 推荐: 默认配置 ✅


资源受限环境:
├── keep_alive: 5-10m
├── 特点: 内存有限
├── 优化: 节省资源
└-- 推荐: 快速回收


突发负载频繁:
├── keep_alive: 45-60m
├── 特点: 偶尔高峰
├-- 优化: 快速响应
└-- 推荐: 长时间保活


负载波动大:
├── keep_alive: 10-20m
├── 特点: 高峰低谷明显
├-- 优化: 平衡资源
└-- 推荐: 中等时间


高性能需求:
├── keep_alive: 60m+
├── 特点: 性能优先
├── 资源: 充足
└-- 推荐: 长时间保活

性能调优 #

keep_alive 调优指南

调优原则:
├── 从默认值开始
├── 观察负载模式
├── 监控资源使用
├── 测试不同配置
└-- 选择最佳值


关键指标:
├── 负载高峰频率
├── 高峰持续时间
├── 资源使用情况
└-- 响应时间要求


调优策略:

负载间隔长 (>1小时):
├── keep_alive: 5-15m
├── 原因: 快速释放资源
└-- 节省资源 ✅


负载间隔中 (15-60分钟):
├── keep_alive: 30m (默认)
├── 原因: 可能连续高峰
└-- 平衡配置 ✅


负载间隔短 (<15分钟):
├── keep_alive: 45-60m
├── 原因: 保持线程活跃
└-- 快速响应 ✅


完全不可预测:
├── keep_alive: 30-45m
├── 原因: 中等策略
└-- 稳妥选择 ✅

最佳实践 #

keep_alive 配置最佳实践

1. 从默认值开始
   ├── 使用 30m 作为起点
   ├── 观察实际效果
   ├── 根据需要调整
   └-- 避免过度调优


2. 监控负载模式
   ├── 记录负载高峰
   ├── 分析高峰间隔
   ├── 评估持续时间
   └-- 确定配置需求


3. 资源平衡
   ├── 考虑内存限制
   ├── 考虑 CPU 能力
   ├── 平衡性能和资源
   └-- 避免浪费


4. 定期审查
   ├── 定期检查配置
   ├── 评估负载变化
   ├── 调整配置
   └-- 保持优化


5. 测试验证
   ├── 压力测试不同配置
   ├── 测量资源使用
   ├── 验证响应时间
   └-- 选择最佳配置