配置项作用 #
jobscheduler.threadpool.size 配置项用于控制作业调度器线程池的核心线程数量，即同时可以执行的作业调度任务的最大并发数。
此配置决定了作业调度器可以并发处理的任务数量，影响作业调度的吞吐能力和 CPU 资源利用。
配置项属性 #
- 配置路径:
jobscheduler.threadpool.size - 数据类型:
Integer（整数） - 默认值:
Runtime.getRuntime().availableProcessors()（CPU 核心数） - 最小值:
1 - 最大值: 建议不超过 CPU 核心数
- 是否可选: 是（通常自动计算）
- 作用域: NodeScope（节点级别）
- 动态更新: 否（需要重启节点生效）
配置项详解 #
工作机制 #
固定线程池模型
Fixed Executor:
├── 核心线程数: size (默认 = CPU 核心数)
├── 队列大小: queue_size (默认 = 200)
├── 线程类型: 固定大小线程池
└── 执行策略: 核心线程始终存活
任务处理流程:
新任务提交
│
↓
核心线程有空闲?
│
├──── 是 → 空闲线程立即执行 ✅
│
└──── 否 → 队列未满?
│
├──── 是 → 加入队列等待 ⏸
│
└──── 否 → 拒绝任务 ❌
执行中的任务:
├── 占用核心线程
├── 完成后线程继续存活
└── 等待下一个任务
默认值计算 #
线程池大小自动计算
默认值:
size = availableProcessors()
获取方式:
Runtime.getRuntime().availableProcessors()
示例:
4 核 CPU:
size = 4
8 核 CPU:
size = 8
16 核 CPU:
size = 16
可通过 node.processors 覆盖:
node.processors: 4
→ size = 4 (无论实际 CPU 核心数)
并发执行分析 #
假设 CPU 有 4 个核心，size = 4
时刻 T0:
任务1 ──→ 核心1 ──→ 执行中 ⚙️
任务2 ──→ 核心2 ──→ 执行中 ⚙️
任务3 ──→ 核心3 ──→ 执行中 ⚙️
任务4 ──→ 核心4 ──→ 执行中 ⚙️
任务5 ──→ 队列 ──→ 等待 ⏸
并发: 4
时刻 T1 (任务1 完成):
任务1 ──→ 完成 ✅
核心1 ──→ 空闲 ──→ 从队列取任务5
任务2 ──→ 核心2 ──→ 执行中 ⚙️
任务3 ──→ 核心3 ──→ 执行中 ⚙️
任务4 ──→ 核心4 ──→ 执行中 ⚙️
任务5 ──→ 核心1 ──→ 执行中 ⚙️
并发: 4
配置建议 #
生产环境（默认） #
# 不需要显式配置，使用默认值
# size = CPU 核心数
建议: 保持默认值（CPU 核心数）。自动适配硬件。
高性能服务器 #
node:
processors: 16 # 16 核 CPU
jobscheduler:
threadpool:
size: 16 # 显式设置
建议: 设置为 CPU 核心数。充分利用 CPU。
混合负载节点 #
node:
processors: 8
jobscheduler:
threadpool:
size: 4 # 限制线程数
建议: 设置为 CPU 核心数的一半。节点承担多种职责时使用。
资源受限环境 #
jobscheduler:
threadpool:
size: 2 # 减少线程数
建议: 设置为 2-4。CPU 资源紧张时使用。
代码示例 #
easysearch.yml 基础配置 #
# 通常不需要配置，使用默认值
# size 自动 = CPU 核心数
显式配置大小 #
jobscheduler:
threadpool:
size: 8
queue_size: 500
通过 node.processors 配置 #
node:
processors: 4
# jobscheduler.threadpool.size 将使用此值
高负载配置 #
jobscheduler:
threadpool:
size: 16
queue_size: 1000
sweeper:
period: 10m
相关配置 #
| 配置项 | 作用 | 默认值 |
|---|---|---|
jobscheduler.threadpool.size | 线程池大小 | CPU 核心数 |
jobscheduler.threadpool.queue_size | 队列大小 | 200 |
node.processors | 覆盖 CPU 核心数检测 | 自动检测 |
性能影响分析 #
| size 设置 | 优点 | 缺点 |
|---|---|---|
| 1-2 | CPU 占用低 | 吞吐量低 |
| CPU/2 | 平衡负载 | 标准设置 |
| CPU（默认） | 最大吞吐 | 高 CPU 占用 |
| CPU×2 | 不推荐 | 上下文切换高 |
吞吐量对比 #
假设每个任务执行 100ms
size = 2:
├── 并发执行: 2
├── 每秒处理: 2 × (1000ms / 100ms) = 20 个任务
└── CPU 利用: ~50%
size = 4 (CPU = 4):
├── 并发执行: 4
├── 每秒处理: 4 × (1000ms / 100ms) = 40 个任务
└── CPU 利用: ~100% ✅
size = 8 (CPU = 4):
├── 并发执行: 8 (但只有 4 个核心)
├── 实际吞吐: ~40 个任务
└── CPU 利用: ~100% + 上下文切换开销 ❌
使用场景 #
推荐使用默认值的场景 #
- 专用节点: 节点专门用于作业调度
- 标准负载: 任务数量适中
- CPU 充足: CPU 资源充足
- 自动适配: 希望自动适配硬件
推荐增加线程数的场景 #
- 多核 CPU: CPU 核心数很多（如 16 核+）
- 计算密集: 任务主要是计算密集型
- 高吞吐需求: 需要更高的吞吐量
推荐减少线程数的场景 #
- 混合节点: 节点同时承担其他职责
- IO 密集: 任务主要是等待 IO
- 资源受限: CPU 资源紧张
- 稳定性优先: 优先考虑系统稳定性
与队列大小的配合 #
size 和 queue_size 的协同
配置 1: 标准配置
size: 4
queue_size: 200
├── 并发执行: 4
├── 队列等待: 200
├── 总容量: 204
└── 适合: 4 核 CPU
配置 2: 高并发配置
size: 8
queue_size: 500
├── 并发执行: 8
├── 队列等待: 500
├── 总容量: 508
└── 适合: 8 核 CPU
配置 3: 低资源配置
size: 2
queue_size: 100
├── 并发执行: 2
├── 队列等待: 100
├── 总容量: 102
└── 适合: 2 核 CPU
CPU 利用分析 #
不同 size 的 CPU 利用
假设 4 核 CPU，任务为计算密集型
size = 1:
核心1: ████████████ 100%
核心2: ░░░░░░░░░░░░ 0%
核心3: ░░░░░░░░░░░░ 0%
核心4: ░░░░░░░░░░░░ 0%
总利用: 25% ❌
size = 2:
核心1: ████████████ 100%
核心2: ████████████ 100%
核心3: ░░░░░░░░░░░░ 0%
核心4: ░░░░░░░░░░░░ 0%
总利用: 50%
size = 4 (默认):
核心1: ████████████ 100%
核心2: ████████████ 100%
核心3: ████████████ 100%
核心4: ████████████ 100%
总利用: 100% ✅
size = 8:
核心1: ████████████ 100%
核心2: ████████████ 100%
核心3: ████████████ 100%
核心4: ████████████ 100%
总利用: 100% + 上下文切换开销 ❌
注意事项 #
默认值: 默认为 CPU 核心数，通常最优。
需要重启: 修改此配置需要重启节点。
过犹不及: 设置超过 CPU 核心数会增加上下文切换。
node.processors: 可通过
node.processors覆盖检测值。混合负载: 混合节点应减少线程数。
队列配合: 应与
queue_size配合配置。监控建议: 监控 CPU 利用率和任务完成率。
测试验证: 配置变更后应验证吞吐量和稳定性。
计算密集: 计算密集任务建议 size = CPU 核心数。
IO 密集: IO 密集任务可以适当增加 size。
线程池类型 #
Fixed Executor 特点
固定大小线程池:
├── 核心线程数 = 最大线程数
├── 核心线程始终存活
├── 无空闲超时回收
├── 队列满时拒绝任务
└── 适合: 稳定负载场景
与 Cached Executor 对比:
Fixed:
├── 线程数固定
├── 无创建/销毁开销
└── 适合: 长期运行的任务
Cached:
├── 线程数动态增长
├── 有创建/销毁开销
└── 适合: 短期大量任务
