配置项作用 #
node.processors 配置项用于控制节点使用的处理器（CPU 核心）数量。
此配置影响节点内部线程池的大小计算，是性能调优的重要参数。如果不配置，系统会自动检测可用的 CPU 核心数。
配置项属性 #
- 配置路径:
node.processors - 数据类型:
Integer（整数值） - 默认值:
Runtime.getRuntime().availableProcessors()（自动检测） - 最小值:
1 - 是否可选: 是
- 作用域: NodeScope（节点级别）
- 动态更新: 否（需要重启节点生效）
配置项详解 #
工作机制 #
处理器数量工作机制
自动检测（默认）:
node.processors: 未设置
│
↓
Runtime.getRuntime().availableProcessors()
│
├── 返回 CPU 核心数
├── 例如: 8 核 CPU → 8
└── 作为节点处理器数
手动设置:
node.processors: 4
│
├── 使用指定值
├── 忽略自动检测
└── 线程池基于此值计算
值超过实际 CPU:
node.processors: 16 (实际只有 8 核)
│
├── 节点正常工作
├── 输出弃用警告 ⚠️
└── 可能导致过度并发
线程池计算 #
线程池大小计算
通用公式:
thread_pool_size = node.processors × 某个系数
各线程池示例:
1. search 线程池
processors: 8
size: int((8 * 3) / 2) + 1 = 13
2. generic 线程池
processors: 8
core: around(8 * 0.5) = 4
max: around(8 * 3) = 24
3. write 线程池
processors: 8
size: around(8 * 2) = 16
4. get 线程池
processors: 8
size: around(8 * 2) = 16
影响:
├── 线程数增加 → CPU 利用率 ↑
├── 线程数过多 → 上下文切换 ↑
└── 需要合理配置 ✅
自动检测机制 #
自动检测详细机制
Java API:
Runtime.getRuntime().availableProcessors()
│
├── 返回逻辑处理器数量
├── 考虑超线程
├── 考虑 CPU 亲和性
└── 考虑容器 cgroups
不同环境:
物理机 (8 核, 无超线程):
availableProcessors() = 8
物理机 (4 核, 超线程):
availableProcessors() = 8
Docker 容器 (无限制):
availableProcessors() = 宿主机 CPU 数
例如: 宿机 16 核 → 容器看到 16
Docker 容器 (有 CPU 限制):
availableProcessors() = 配额限制
例如: --cpus="2" → 返回 2
Kubernetes Pod:
resources:
limits:
cpu: "2"
availableProcessors() = 2
容器环境注意事项 #
容器环境 CPU 限制
问题: Java 无法感知容器 CPU 限制
Docker (未正确配置):
docker run --cpus="2" es:latest
│
├── Java 看到宿机 CPU 数 (例如 16)
├── 线程池按 16 核计算
├── 实际只有 2 核可用
└── 性能问题 ❌
解决方法 1: 手动设置
node.processors: 2
解决方法 2: JDK 8u191+ 自动感知
java -XX:+UseContainerSupport
│
├── 自动检测容器限制
├── availableProcessors() 正确
└── 推荐使用 ✅
解决方法 3: JVM 参数
java -XX:ActiveProcessorCount=2
│
├── 覆盖检测值
└── 与 node.processors 效果相同
配置建议 #
生产环境（自动检测） #
# 不配置，使用自动检测
# node.processors 不设置
建议: 保持自动检测。适用于物理机和正确配置的容器。
容器环境（手动设置） #
node:
processors: 2 # 匹配容器 CPU 限制
建议: 容器环境且 JVM 版本低于 8u191 时手动设置。
共享主机环境 #
node:
processors: 4 # 限制使用的核心数
建议: 多实例共享同一主机时，限制每个实例的核心数。
测试环境 #
node:
processors: 1 # 限制资源使用
建议: 测试环境设置为 1，减少资源消耗。
性能调优 #
node:
processors: 8 # 根据实际负载调整
建议: 根据实际负载和性能测试结果调整。
代码示例 #
easysearch.yml 基础配置 #
# 不设置，使用自动检测
# 默认行为
容器环境配置 #
# Docker 容器，限制 2 核
node:
name: "es-container"
processors: 2
共享主机配置 #
# 16 核主机，运行 4 个实例
node:
name: "es-instance-1"
processors: 4 # 每实例使用 4 核
性能优化配置 #
# 特定负载优化
node:
processors: 16 # 高负载场景
# 需要确保有足够的 CPU 资源
完整配置示例 #
cluster:
name: "production-cluster"
node:
name: "data-node-1"
processors: 8
# 线程池会基于 8 个处理器计算
thread_pool:
search:
size: 13 # 可选：显式覆盖计算值
相关配置 #
| 配置项 | 作用 | 默认值 |
|---|---|---|
node.processors | 处理器数量 | 自动检测 |
thread_pool.*.size | 线程池大小 | 基于 processors 计算 |
processes (旧) | 旧的配置项名称 | 已废弃 |
性能影响分析 #
| node.processors 设置 | 优点 | 缺点 |
|---|---|---|
| 自动检测 | 简化配置 | 容器环境可能不准 |
| 匹配实际 CPU | 最佳性能 | 需要手动配置 |
| 低于实际 CPU | 稳定、共享友好 | 性能未充分利用 |
| 高于实际 CPU | - | 过度并发、性能下降 |
性能影响详解 #
性能影响分析
1. 设置正确 (processors = 实际 CPU)
├── 线程数合理
├── CPU 充分利用
├── 上下文切换适中
└── 最佳性能 ✅
2. 设置过低 (processors < 实际 CPU)
8核设置: processors: 4
├── 线程数减少
├── CPU 未充分利用
├── 吞吐量可能降低
├── 系统更稳定 ✅
└── 共享环境友好 ✅
3. 设置过高 (processors > 实际 CPU)
4核设置: processors: 8
├── 线程数过多
├── 上下文切换频繁
├── CPU 浪费在切换上
├── 性能下降 ❌
└── 响应延迟增加
过度并发症状:
├── CPU 使用率高但吞吐低
├── 上下文切换频繁
├── 响应时间增加
└── 系统负载高
使用场景 #
推荐使用自动检测的场景 #
- 物理机部署: CPU 数量固定且已知
- 独立虚拟机: 独占 CPU 资源
- 新版本 JVM: 8u191+ 自动感知容器限制
- 标准部署: 大多数生产环境
推荐手动设置的场景 #
- 容器环境: JVM 版本低于 8u191
- CPU 限制: 容器/Pod 有 CPU 限制
- 共享主机: 多实例共享 CPU
- 性能调优: 需要精确控制并发
容器环境配置 #
容器环境配置指南
Docker 配置:
# 1. 设置 CPU 限制
docker run -d --name es \
--cpus="4" \
-e "ES_JAVA_OPTS=-XX:+UseContainerSupport" \
easysearch:latest
# 2. 或手动设置 processors
docker run -d --name es \
--cpus="4" \
easysearch:latest
Kubernetes 配置:
apiVersion: v1
kind: Pod
spec:
containers:
- name: easysearch
image: easysearch:latest
resources:
limits:
cpu: "4"
env:
- name: ES_JAVA_OPTS
value: "-XX:+UseContainerSupport"
配置文件 (JVM < 8u191):
# easysearch.yml
node:
processors: 4 # 匹配资源限制
性能调优建议 #
性能调优流程
1. 监控当前性能
├── CPU 使用率
├── 线程池状态
├── 上下文切换次数
└── 响应时间
2. 分析瓶颈
├── CPU 未用满 → 增加 processors
├── 上下文切换多 → 减少 processors
├── 响应慢 → 检查线程池
└── 综合判断
3. 测试不同配置
├── processors: 4 → 测试
├── processors: 8 → 测试
├── processors: 16 → 测试
└── 测量性能指标
4. 选择最优值
├── CPU 充分利用
├── 上下文切换适中
├── 响应时间合理
└── 吞吐量最优
5. 验证稳定性
├── 长时间运行测试
├── 压力测试
└── 监控系统健康
注意事项 #
默认值: 默认自动检测 CPU 核心数。
需要重启: 修改此配置需要重启节点。
最小值: 最小值为 1，不能设置为 0。
容器感知: 新版本 JVM (8u191+) 自动感知容器限制。
超线程:
availableProcessors()包含超线程核心。线程池影响: 影响多个线程池的大小。
过度配置: 超过实际 CPU 会降低性能。
弃用警告: 配置值超过实际 CPU 会输出警告。
旧配置:
processors配置项已废弃，使用node.processors。性能测试: 修改后应进行性能测试验证。
JVM 配置配合 #
JVM 配置配合
1. 容器支持
java -XX:+UseContainerSupport \
-XX:ActiveProcessorCount=4
2. 直接设置
java -XX:ActiveProcessorCount=4 \
-jar easysearch.jar
3. 与 node.processors 的关系
node.processors: 4
等效于:
java -XX:ActiveProcessorCount=4
4. 优先级
XX:ActiveProcessorCount > availableProcessors()
如果设置了 JVM 参数，优先使用 JVM 参数值
推荐配置:
# JVM 自动感知容器
ES_JAVA_OPTS=-XX:+UseContainerSupport
# 或明确指定
node:
processors: 4
最佳实践 #
processors 配置最佳实践
1. 物理机
├── 使用自动检测
├── 不设置 node.processors
├── 充分利用 CPU
└── 最佳性能 ✅
2. 容器 (JVM >= 8u191)
├── 启用容器支持
├── 不设置 node.processors
├── JVM 自动检测
└── 推荐 ✅
3. 容器 (JVM < 8u191)
├── 手动设置 processors
├── 匹配 CPU 限制
├── 避免过度配置
└── 必要 ✅
4. 共享主机
├── 评估每个实例配额
├── 设置合理 processors
├── 避免竞争
└── 稳定优先 ✅
5. 性能调优
├── 监控 → 分析 → 调整
├── 基于实际测试
├── 逐步调整
└── 验证效果
