📣 极限科技诚招搜索运维工程师(Elasticsearch/Easysearch)- 全职/北京 👉 : 立即申请加入

配置项作用 #

monitor.jvm.gc.refresh_interval 配置项用于控制JVM GC 监控服务的检查刷新间隔时间

此配置决定了 JVM GC 监控服务多久检查一次 GC 活动,收集和监控 GC 的统计信息,检查 GC 是否超过预设的阈值。

配置项属性 #

  • 配置路径: monitor.jvm.gc.refresh_interval
  • 数据类型: TimeValue(时间值)
  • 默认值: 1s(1秒)
  • 最小值: 1s(1秒)
  • 是否可选: 是
  • 作用域: NodeScope(节点级别)
  • 动态更新: 否(需要重启节点生效)

配置项详解 #

工作机制 #

GC 监控定时任务

scheduleWithFixedDelay 策略:

上次检查完成
    │
    ↓ 等待 refresh_interval
    │
    ↓
触发本次检查
    │
    ├── 获取当前 GC 时间
    ├── 计算间隔内 GC 耗时
    ├── 计算 GC 开销百分比
    ├── 检查慢 GC 阈值
    ├── 检查 GC 开销阈值
    └── 记录相应日志
    │
    ↓ 检查完成
    ↓
等待 refresh_interval
    │
    ↓ (循环)


示例 (refresh_interval = 1s):

00:00.000 ──→ 检查 1 开始
00:00.100 ──→ 检查 1 完成
00:01.100 ──→ 检查 2 开始
00:01.200 ──→ 检查 2 完成
00:02.200 ──→ 检查 3 开始
...

GC 监控内容 #

每次监控检查的内容

1. GC 时间统计
   ├── 获取各个 GC 收集器的累计时间
   ├── 计算间隔内新增的 GC 时间
   └── 计算总耗时


2. GC 开销计算
   fraction = (GC 时间 / 总时间) × 100
   ├── 与 DEBUG 阈值比较
   ├── 与 INFO 阈值比较
   └── 与 WARN 阈值比较


3. 慢 GC 检测
   ├── 检查单次 GC 耗时
   ├── 与慢 GC 阈值比较
   └── 记录慢 GC 日志


4. 日志记录
   ├── DEBUG 级别: 轻微 GC 压力
   ├── INFO 级别: 明显 GC 压力
   └── WARN 级别: 严重 GC 问题

与 JVM 监控的关系 #

两种刷新间隔的区别

monitor.jvm.refresh_interval:
├── 作用: JVM 基础监控信息刷新
├── 内容: 内存、线程、类加载等
├── 默认: 1s
└── 文件: JvmService.java


monitor.jvm.gc.refresh_interval:
├── 作用: GC 专项监控刷新
├── 内容: GC 时间、GC 开销、慢 GC
├── 默认: 1s
└── 文件: JvmGcMonitorService.java


两者独立:
├── 分别控制不同监控模块
├── 可以独立配置
└── 都是 1s 默认值

配置建议 #

生产环境(默认) #

monitor:
  jvm:
    gc:
      refresh_interval: 1s  # 默认值

建议: 保持默认值 1s。及时监控 GC 状况。

降低监控频率 #

monitor:
  jvm:
    gc:
      refresh_interval: 5s  # 减少频率

建议: 设置为 3-5s。减少监控开销时使用。

高频监控 #

monitor:
  jvm:
    gc:
      refresh_interval: 500ms  # 更频繁

建议: 设置为 500ms。需要更细致监控时使用。

低频监控 #

monitor:
  jvm:
    gc:
      refresh_interval: 10s  # 低频率

建议: 设置为 10-30s。稳定的系统,减少开销。

代码示例 #

easysearch.yml 基础配置 #

monitor:
  jvm:
    gc:
      enabled: true
      refresh_interval: 1s

标准生产配置 #

monitor:
  jvm:
    gc:
      enabled: true
      refresh_interval: 1s
      overhead:
        debug: 10
        info: 25
        warn: 50

低开销配置 #

monitor:
  jvm:
    gc:
      enabled: true
      refresh_interval: 5s

高频监控配置 #

monitor:
  jvm:
    gc:
      enabled: true
      refresh_interval: 500ms
      overhead:
        debug: 5
        info: 15
        warn: 30

相关配置 #

配置项作用默认值
monitor.jvm.gc.enabled是否启用 GC 监控true
monitor.jvm.gc.refresh_intervalGC 监控刷新间隔1s
monitor.jvm.gc.overhead.debugDEBUG 阈值10%
monitor.jvm.gc.overhead.infoINFO 阈值25%
monitor.jvm.gc.overhead.warnWARN 阈值50%

性能影响分析 #

refresh_interval 设置优点缺点
500ms最详细监控较高监控开销
1s(默认)及时发现问题标准设置
3-5s低监控开销检测延迟
10s+最低开销检测延迟大

检测延迟对比 #

GC 问题的检测延迟

refresh_interval = 500ms:
├── GC 问题发生: 00:00.000
├── 下次检查: 00:00.500
├── 检测延迟: 最多 500ms ✅
└── 每秒检查: 2 次


refresh_interval = 1s (默认):
├── GC 问题发生: 00:00.000
├── 下次检查: 00:01.000
├── 检测延迟: 最多 1 秒
└── 每秒检查: 1 次


refresh_interval = 5s:
├── GC 问题发生: 00:00.000
├── 下次检查: 00:05.000
├── 检测延迟: 最多 5 秒
└── 每分钟检查: 12 次


refresh_interval = 10s:
├── GC 问题发生: 00:00.000
├── 下次检查: 00:10.000
├── 检测延迟: 最多 10 秒 ⚠️
└── 每分钟检查: 6 次

使用场景 #

推荐使用默认值的场景 #

  • 生产环境: 大多数生产环境
  • 及时监控: 需要及时发现 GC 问题
  • 标准应用: 正常的 Java 应用

推荐增加间隔的场景 #

  • 稳定系统: GC 状况很稳定
  • 减少开销: 希望减少监控开销
  • 长期运行: 长期运行的服务
  • 资源受限: 系统资源紧张

推荐减少间隔的场景 #

  • 性能调优: 正在进行性能优化
  • 问题排查: 排查 GC 相关问题
  • 关键应用: 对 GC 极其敏感
  • 调试环境: 开发或测试环境

与阈值配置的配合 #

监控间隔和阈值的配合

高频监控 + 低阈值:
refresh_interval: 500ms
debug: 5%
info: 10%
warn: 20%
└── 最详细的 GC 监控


标准配置:
refresh_interval: 1s  ✅
debug: 10%  ✅
info: 25%  ✅
warn: 50%  ✅
└── 平衡的监控


低频监控 + 高阈值:
refresh_interval: 10s
debug: 20%
info: 40%
warn: 70%
└── 宽松的监控

监控开销分析 #

监控本身的性能开销

refresh_interval = 500ms:
├── 每秒检查: 2 次
├── 每小时检查: 7200 次
├── 单次开销: ~0.1ms
└── 每小时开销: ~720ms (0.02%)


refresh_interval = 1s (默认):
├── 每秒检查: 1 次
├── 每小时检查: 3600 次
├── 单次开销: ~0.1ms
└── 每小时开销: ~360ms (0.01%) ✅


refresh_interval = 5s:
├── 每秒检查: 0.2 次
├── 每小时检查: 720 次
├── 单次开销: ~0.1ms
└── 每小时开销: ~72ms (0.002%)


refresh_interval = 10s:
├── 每秒检查: 0.1 次
├── 每小时检查: 360 次
├── 单次开销: ~0.1ms
└── 每小时开销: ~36ms (0.001%)

注意事项 #

  1. 默认值: 默认值为 1s,适合大多数场景。

  2. 最小值: 最小值为 1s,不能设置更小。

  3. 需要重启: 修改此配置需要重启节点。

  4. 固定延迟: 使用 scheduleWithFixedDelay 策略。

  5. 监控开销: 监控本身有一定的性能开销。

  6. 检测延迟: 间隔越长,问题检测延迟越大。

  7. 与阈值配合: 应与 GC 阈值配置配合。

  8. 独立配置: 与 monitor.jvm.refresh_interval 是独立的。

  9. 线程池: 使用 SAME 线程池执行。

  10. 测试验证: 配置变更后应验证监控效果。

GC 监控初始化 #

GC 监控服务初始化

1. 读取配置
   ├── enabled: 是否启用
   ├── refresh_interval: 检查间隔
   └── gc_overhead_*: 阈值配置


2. 创建监控任务
   ├── JvmMonitor 实例
   ├── 传入 GC 阈值
   └── 传入 GC 开销阈值


3. 启动定时任务
   ├── scheduleWithFixedDelay
   ├── 间隔: refresh_interval
   └── 线程池: Names.SAME


4. 开始监控
   ├── 定期执行检查
   ├── 记录日志
   └── 触发告警