配置项作用 #
monitor.jvm.gc.overhead.warn 配置项用于控制JVM 垃圾回收（GC）开销的 WARN 级别日志阈值。
当 GC 开销（GC 时间占总时间的百分比）达到或超过此阈值时，系统会记录 WARN 级别的日志，警告严重的 GC 问题，需要立即关注和处理。
配置项属性 #
- 配置路径:
monitor.jvm.gc.overhead.warn - 数据类型:
Integer（整数） - 默认值:
50（50%） - 取值范围:
0-100（百分比） - 是否可选: 是
- 作用域: NodeScope（节点级别）
- 动态更新: 否（需要重启节点生效）
配置项详解 #
工作机制 #
GC 开销监控流程
监控周期: refresh_interval (默认 1s)
每个周期:
├── 记录上次 GC 时间
├── 记录当前 GC 时间
├── 计算周期总耗时
├── 计算 GC 开销百分比
└── 判断日志级别
GC 开销计算:
fraction = (GC 时间 / 总时间) × 100
日志级别判断:
if (fraction >= warn_threshold) {
→ WARN 日志 ⚠️
} else if (fraction >= info_threshold) {
→ INFO 日志 ℹ️
} else if (fraction >= debug_threshold) {
→ DEBUG 日志 🔍
} else {
→ 不记录日志
}
阈值层级 #
三个 GC 开销阈值
默认配置:
├── WARN: 50%
├── INFO: 25%
└── DEBUG: 10%
阈值关系:
WARN (50%) > INFO (25%) > DEBUG (10%)
日志输出:
GC 开销 = 30%:
├── 30% < 50% (WARN)
├── 30% >= 25% (INFO)
└── 记录 INFO 日志 ℹ️
GC 开销 = 50%:
├── 50% >= 50% (WARN)
└── 记录 WARN 日志 ⚠️
GC 开销 = 70%:
├── 70% >= 50% (WARN)
└── 记录 WARN 日志 ⚠️
WARN 日志示例 #
WARN 日志格式
[gc][{seq}] overhead, spent [{gc_time}] collecting in the last [{total_time}]
示例:
[gc][8] overhead, spent [6000ms] collecting in the last [10000ms]
├── 序列号: 8
├── GC 时间: 6000ms
├── 总时间: 10000ms
├── GC 开销: 60%
└── 级别: WARN (60% >= 50%)
严重性:
├── 超过一半的 CPU 时间在 GC
├── 应用性能严重下降
├── 可能出现卡顿
└── 需要立即处理 ⚠️
配置建议 #
生产环境（默认） #
monitor:
jvm:
gc:
overhead:
warn: 50 # 默认值
建议: 保持默认值 50%。适用于大多数生产环境。
高负载环境 #
monitor:
jvm:
gc:
overhead:
warn: 60 # 提高阈值
建议: 设置为 60-70%。GC 开销本来就高的环境。
严格监控 #
monitor:
jvm:
gc:
overhead:
warn: 40 # 降低阈值
建议: 设置为 35-45%。需要更早发现问题。
批处理环境 #
monitor:
jvm:
gc:
overhead:
warn: 70
info: 50
建议: 设置为 70%。批处理等可容忍高 GC 开销的场景。
代码示例 #
easysearch.yml 基础配置 #
monitor:
jvm:
gc:
overhead:
debug: 10
info: 25
warn: 50
严格监控配置 #
monitor:
jvm:
gc:
overhead:
debug: 5
info: 15
warn: 30
高负载配置 #
monitor:
jvm:
gc:
overhead:
debug: 15
info: 35
warn: 65
批处理配置 #
monitor:
jvm:
gc:
overhead:
debug: 20
info: 50
warn: 75
相关配置 #
| 配置项 | 作用 | 默认值 |
|---|---|---|
monitor.jvm.gc.overhead.debug | DEBUG 阈值 | 10% |
monitor.jvm.gc.overhead.info | INFO 阈值 | 25% |
monitor.jvm.gc.overhead.warn | WARN 阈值 | 50% |
monitor.jvm.gc.refresh_interval | 监控刷新间隔 | 1s |
阈值约束 #
配置约束规则
必须满足:
WARN > INFO > DEBUG
错误示例:
debug: 10
info: 25
warn: 30 ❌ (WARN 必须 > INFO)
正确示例:
debug: 10
info: 25 ✅
warn: 50
启动验证:
if (warn <= info) {
throw IllegalArgumentException(
"monitor.jvm.gc.overhead.warn must be greater than monitor.jvm.gc.overhead.info"
)
}
使用场景 #
推荐使用默认值的场景 #
- 标准应用: 正常的 Java 应用
- 生产环境: 大多数生产环境
- 在线服务: 在线事务处理系统
推荐降低阈值的场景 #
- 低延迟要求: 对延迟极其敏感
- 实时系统: 实时数据处理
- 关键应用: 业务非常关键
- 性能优先: 性能优先的场景
推荐提高阈值的场景 #
- 批处理: 批处理作业
- 数据分析: 数据分析任务
- 离线任务: 离线数据处理
- 高内存应用: 内存密集型应用
GC 开销分析 #
GC 开销的影响和应对
GC 开销 < 10%:
├── 状态: 优秀 ✅
├── 应用流畅
└── 无需关注
GC 开销 10-25% (DEBUG):
├── 状态: 良好
├── 有一定 GC 压力
├── 建议关注
└── 记录 DEBUG 日志
GC 开销 25-50% (INFO):
├── 状态: 警告 ℹ️
├── GC 压力较大
├── 应用性能下降
├── 应该优化
└── 记录 INFO 日志
GC 开销 > 50% (WARN):
├── 状态: 严重 ⚠️
├── 大量时间在 GC
├── 应用明显卡顿
├── 用户体验差
├── 必须处理
└── 记录 WARN 日志
紧急处理流程 #
触发 WARN 时的处理
WARN 日志出现:
[gc][8] overhead, spent [6000ms] collecting in the last [10000ms]
│
↓
立即检查:
├── 查看堆内存使用情况
├── 检查是否有内存泄漏
├── 查看老年代使用情况
└── 分析 GC 日志
│
↓
短期措施:
├── 如果可能，重启节点
├── 临时增加堆内存
├── 限流或降级服务
└── 监控情况变化
│
↓
长期解决:
├── 分析内存分配模式
├── 优化对象分配策略
├── 检查是否有内存泄漏
├── 调整 GC 策略
└── 考虑架构调整
性能调优建议 #
基于 GC 开销的调优策略
GC 开销持续 > 50% (WARN 阈值):
紧急措施:
├── 立即增加堆内存
├── 重启节点释放内存
├── 限流保护
└── 升级配置
根本解决:
├── 检查内存泄漏
│ ├── 使用 heap dump 分析
│ ├── 检查缓存使用
│ └── 检查集合类使用
│
├── 优化对象分配
│ ├── 减少临时对象
│ ├── 使用对象池
│ └── 优化数据结构
│
├── 调整 GC 策略
│ ├── G1 GC: 平衡
│ ├── ZGC: 低延迟
│ └── Parallel: 高吞吐
│
└── 调整 GC 参数
├── 调整新生代大小
├── 调整老年代阈值
└── 调整 GC 线程数
注意事项 #
阈值关系: 必须满足
WARN > INFO > DEBUG。严重级别: WARN 是最高的 GC 开销警告级别。
立即处理: 触发 WARN 级别应该立即处理。
百分比单位: 配置值是百分比（0-100）。
启动验证: 启动时会验证配置的正确性。
性能影响: GC 开销超过 50% 会严重影响性能。
用户体验: 用户会明显感觉到卡顿。
配合调整: 应与堆内存配置配合调整。
紧急程度: WARN 级别需要紧急处理。
持续监控: 持续监控直到问题解决。
与应用类型的匹配 #
不同应用类型的建议配置
低延迟应用 (交易、游戏):
├── WARN: 30%
├── INFO: 15%
└── DEBUG: 5%
└── 严格控制 GC 开销
标准应用 (Web服务):
├── WARN: 50% ✅
├── INFO: 25% ✅
└── DEBUG: 10% ✅
└── 使用默认配置
批处理应用 (数据处理):
├── WARN: 70%
├── INFO: 50%
└── DEBUG: 20%
└── 可以容忍更高 GC 开销
