--- title: "JVM GC 开销信息阈值配置" date: 2026-02-24 lastmod: 2026-02-24 description: "monitor.jvm.gc.overhead.info 配置项用于控制 JVM GC 开销的 INFO 级别日志阈值。" tags: ["监控", "JVM", "GC", "性能调优"] summary: "配置项作用 # 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` 配置项用于控制**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 上 ├── 应用性能可能受到影响 └── 需要关注内存配置 ``` ## 配置建议 ## 生产环境（默认） ```yaml monitor: jvm: gc: overhead: info: 25 # 默认值 ``` **建议**: 保持默认值 `25%`。适用于大多数生产环境。 ## 高负载环境 ```yaml monitor: jvm: gc: overhead: info: 35 # 提高阈值 ``` **建议**: 设置为 `30-40%`。GC 开销本来就高的环境。 ## 敏感监控 ```yaml monitor: jvm: gc: overhead: info: 20 # 降低阈值 ``` **建议**: 设置为 `15-20%`。需要更早发现问题。 ## 保守配置 ```yaml monitor: jvm: gc: overhead: info: 40 warn: 60 ``` **建议**: 设置为 `40%`。减少日志量。 ## 代码示例 ## easysearch.yml 基础配置 ```yaml monitor: jvm: gc: overhead: debug: 10 info: 25 warn: 50 ``` ## 敏感监控配置 ```yaml monitor: jvm: gc: overhead: debug: 5 info: 15 warn: 30 ``` ## 高负载配置 ```yaml monitor: jvm: gc: overhead: debug: 15 info: 35 warn: 60 ``` ## 开发调试配置 ```yaml 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" ) } ``` ## 使用场景 ## 推荐使用默认值的场景 - **标准应用**: 正常的 Java 应用 - **生产环境**: 大多数生产环境 - **平衡监控**: 平衡警告和日志量 ## 推荐降低阈值的场景 - **关键应用**: 对性能非常敏感 - **快速响应**: 需要更早发现问题 - **性能优化**: 正在进行性能优化 - **低延迟要求**: 不能容忍 GC 压力 ## 推荐提高阈值的场景 - **高负载环境**: GC 开销本来就高 - **大数据处理**: 批处理等场景 - **减少日志**: 希望减少日志量 - **稳定应用**: 应用非常稳定 ## 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 策略 ``` ## 注意事项 1. **阈值关系**: 必须满足 `WARN > INFO > DEBUG`。 2. **百分比单位**: 配置值是百分比（0-100）。 3. **启动验证**: 启动时会验证配置的正确性。 4. **INFO 级别**: INFO 级别日志通常都会输出。 5. **生产监控**: 生产环境建议关注 INFO 日志。 6. **性能影响**: GC 开销超过 25% 会影响性能。 7. **配合调整**: 应与堆内存配置配合调整。 8. **定期检查**: 定期检查 GC 开销日志。 9. **趋势分析**: 关注 GC 开销的变化趋势。 10. **合理设置**: 根据应用特性合理设置阈值。 ## 与其他监控的配合 ``` GC 监控的完整视图 GC 开销监控: ├── DEBUG: 10% - 详细信息 ├── INFO: 25% - 需要关注 ℹ️ └── WARN: 50% - 严重问题 ⚠️ 其他 GC 监控: ├── GC 次数 ├── GC 时间 ├── 堆内存使用 ├── 老年代使用 └── GC 停顿时间 综合分析: ├── GC 开销高 + GC 次数多 │ └── 可能是堆内存不足 │ ├── GC 开销高 + GC 次数少 │ └── 可能是单次 GC 时间长 │ └── GC 开销高 + 老年代满 └── 可能是内存泄漏 ```