JVM GC 开销信息阈值配置

配置项作用 #

monitor.jvm.gc.overhead.info 配置项用于控制JVM 垃圾回收（GC）开销的 INFO 级别日志阈值。

当 GC 开销（GC 时间占总时间的百分比）达到或超过此阈值时，系统会记录 INFO 级别的日志，提醒运维人员 GC 压力较大。

配置项属性 #

配置路径: monitor.jvm.gc.overhead.info
数据类型: Integer（整数）
默认值: 25（25%）
取值范围: 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 开销 = 15%:
├── 15% < 25% (INFO)
├── 15% >= 10% (DEBUG)
└── 记录 DEBUG 日志 🔍


GC 开销 = 30%:
├── 30% >= 25% (INFO)
├── 30% < 50% (WARN)
└── 记录 INFO 日志 ℹ️


GC 开销 = 60%:
├── 60% >= 50% (WARN)
└── 记录 WARN 日志 ⚠️

INFO 日志示例 #

INFO 日志格式

[gc][{seq}] overhead, spent [{gc_time}] collecting in the last [{total_time}]


示例:

[gc][5] overhead, spent [3000ms] collecting in the last [10000ms]
├── 序列号: 5
├── GC 时间: 3000ms
├── 总时间: 10000ms
├── GC 开销: 30%
└── 级别: INFO (30% >= 25%)


分析:
├── 30% 的 CPU 时间花在 GC 上
├── 应用性能可能受到影响
└── 需要关注内存配置

配置建议 #

生产环境（默认） #

monitor:
  jvm:
    gc:
      overhead:
        info: 25  # 默认值

建议: 保持默认值 25%。适用于大多数生产环境。

高负载环境 #

monitor:
  jvm:
    gc:
      overhead:
        info: 35  # 提高阈值

建议: 设置为 30-40%。GC 开销本来就高的环境。

敏感监控 #

monitor:
  jvm:
    gc:
      overhead:
        info: 20  # 降低阈值

建议: 设置为 15-20%。需要更早发现问题。

保守配置 #

monitor:
  jvm:
    gc:
      overhead:
        info: 40
        warn: 60

建议: 设置为 40%。减少日志量。

代码示例 #

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: 60

开发调试配置 #

monitor:
  jvm:
    gc:
      overhead:
        debug: 3
        info: 10
        warn: 20

配置项	作用	默认值
`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 (info <= debug) {
    throw IllegalArgumentException(
        "monitor.jvm.gc.overhead.info must be greater than monitor.jvm.gc.overhead.debug"
    )
}

使用场景 #

GC 开销分析 #

GC 开销的影响和应对

GC 开销 < 10%:
├── 状态: 优秀 ✅
├── 应用流畅
├── 无需关注
└── 可能记录 DEBUG 日志


GC 开销 10-25% (DEBUG):
├── 状态: 良好
├── 有一定 GC 压力
├── 建议关注
└── 记录 DEBUG 日志


GC 开销 25-50% (INFO):
├── 状态: 警告 ℹ️
├── GC 压力较大
├── 应用性能下降
├── 应该优化
└── 记录 INFO 日志


GC 开销 > 50% (WARN):
├── 状态: 严重 ⚠️
├── 大量时间在 GC
├── 应用明显卡顿
├── 必须处理
└── 记录 WARN 日志

性能调优建议 #

基于 GC 开销的调优策略

GC 开销持续在 25-50% (INFO 阈值):

短期措施:
├── 检查是否有内存泄漏
├── 检查是否有大对象分配
└── 临时增加堆内存


长期优化:
├── 优化对象分配策略
├── 减少临时对象创建
├── 考虑使用对象池
├── 调整 GC 策略
└── 优化数据结构


GC 策略选择:
├── G1 GC: 平衡吞吐和延迟
├── ZGC: 超低延迟
├── CMS: 低延迟 (已废弃)
└── Parallel: 高吞吐

监控指标解读 #

INFO 日志的解读

日志: [gc][5] overhead, spent [3000ms] collecting in the last [10000ms]


含义:
├── 最近 10 秒内
├── 有 3 秒在做 GC
├── GC 开销 = 30%
└── 超过了 INFO 阈值 (25%)


分析:
✓ 堆内存可能不足
✓ 对象分配可能过多
✓ GC 策略可能需要调整
✓ 应用可能需要优化


行动:
1. 检查堆内存配置
2. 检查是否有内存泄漏
3. 分析对象分配模式
4. 考虑调整 GC 策略

注意事项 #

阈值关系: 必须满足 WARN > INFO > DEBUG。
百分比单位: 配置值是百分比（0-100）。
启动验证: 启动时会验证配置的正确性。
INFO 级别: INFO 级别日志通常都会输出。
生产监控: 生产环境建议关注 INFO 日志。
性能影响: GC 开销超过 25% 会影响性能。
配合调整: 应与堆内存配置配合调整。
定期检查: 定期检查 GC 开销日志。
趋势分析: 关注 GC 开销的变化趋势。
合理设置: 根据应用特性合理设置阈值。

与其他监控的配合 #

GC 监控的完整视图

GC 开销监控:
├── DEBUG: 10% - 详细信息
├── INFO: 25% - 需要关注 ℹ️
└── WARN: 50% - 严重问题 ⚠️


其他 GC 监控:
├── GC 次数
├── GC 时间
├── 堆内存使用
├── 老年代使用
└── GC 停顿时间


综合分析:
├── GC 开销高 + GC 次数多
│   └── 可能是堆内存不足
│
├── GC 开销高 + GC 次数少
│   └── 可能是单次 GC 时间长
│
└── GC 开销高 + 老年代满
    └── 可能是内存泄漏

标签

监控 JVM GC 性能调优