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

配置项作用 #

monitor.jvm.refresh_interval 配置项用于控制JVM 监控统计信息的刷新间隔时间

此配置决定了 JvmService 多久刷新一次 JVM 统计信息(如内存使用、线程数、类加载等),避免频繁调用 JVM 接口获取数据。

配置项属性 #

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

配置项详解 #

工作机制 #

Jvm 统计信息缓存机制

JvmService.stats() 方法:

调用 stats()
    │
    ↓
检查距离上次刷新时间
    │
    ├──── 超过 refresh_interval
    │      │
    │      ↓
    │   重新获取 JVM 统计信息
    │   ├── JvmStats.jvmStats()
    │   ├── 内存使用
    │   ├── 线程信息
    │   ├── 类加载信息
    │   ├── GC 信息
    │   └── 更新缓存
    │
    └──── 未超过 refresh_interval
           │
           ↓
        返回缓存数据 ✅


示例 (refresh_interval = 1s):

00:00.000 ──→ stats() → 获取新数据,缓存
00:00.200 ──→ stats() → 返回缓存 ✅
00:00.500 ──→ stats() → 返回缓存 ✅
00:01.001 ──→ stats() → 获取新数据,缓存
00:01.200 ──→ stats() → 返回缓存 ✅

JVM 统计信息内容 #

JvmStats 包含的信息

1. 内存信息
   ├── 堆内存使用
   │   ├── 已用
   │   └── 最大值
   └── 非堆内存使用
       ├── 已用
       └── 最大值


2. 线程信息
   ├── 线程数
   ├── 峰值线程数
   └── 线程状态


3. 类加载信息
   ├── 已加载类数量
   ├── 总加载类数量
   └── 已卸载类数量


4. GC 信息
   ├── GC 收集器信息
   ├── GC 次数
   └── GC 时间


5. 其他信息
   ├── JVM 启动时间
   ├── JVM 运行时间
   └── 时区信息

缓存机制 #

时间戳检查机制

JvmStats jvmStats = JvmStats.jvmStats();
long lastTimestamp = jvmStats.getTimestamp();


每次调用 stats():
currentTimestamp = System.currentTimeMillis();
if (currentTimestamp - lastTimestamp > refreshInterval.millis()) {
    // 超过间隔,重新获取
    jvmStats = JvmStats.jvmStats();
}
return jvmStats;


优点:
├── 减少系统调用
├── 降低 CPU 开销
├── 提高性能
└── 数据一致性


注意:
├── 数据有延迟
├── 不是完全实时
└── 延迟最多 refresh_interval

配置建议 #

生产环境(默认) #

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

建议: 保持默认值 1s。平衡实时性和性能。

减少刷新频率 #

monitor:
  jvm:
    refresh_interval: 5s  # 减少刷新

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

高频监控 #

monitor:
  jvm:
    refresh_interval: 1s  # 保持最小值

建议: 保持 1s(最小值)。需要最及时数据时使用。

低频监控 #

monitor:
  jvm:
    refresh_interval: 30s  # 低频率

建议: 设置为 30-60s。非常稳定的系统使用。

代码示例 #

easysearch.yml 基础配置 #

monitor:
  jvm:
    refresh_interval: 1s

标准生产配置 #

monitor:
  jvm:
    refresh_interval: 1s

低开销配置 #

monitor:
  jvm:
    refresh_interval: 10s

完整监控配置 #

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

相关配置 #

配置项作用默认值
monitor.jvm.refresh_intervalJVM 统计刷新间隔1s
monitor.jvm.gc.refresh_intervalGC 监控刷新间隔1s
monitor.jvm.gc.overhead.warnGC 开销 WARN 阈值50%

性能影响分析 #

refresh_interval 设置优点缺点
1s(默认)及时数据标准开销
5s低系统调用数据延迟 5s
10s很低系统调用数据延迟 10s
30s+最低系统调用数据延迟大

系统调用对比 #

不同间隔的系统调用频率

refresh_interval = 1s:
├── 每分钟调用: 60 次
├── 单次开销: ~0.5ms
└── 每分钟开销: ~30ms (0.05%)


refresh_interval = 5s:
├── 每分钟调用: 12 次
├── 单次开销: ~0.5ms
└── 每分钟开销: ~6ms (0.01%)


refresh_interval = 10s:
├── 每分钟调用: 6 次
├── 单次开销: ~0.5ms
└── 每分钟开销: ~3ms (0.005%)


refresh_interval = 30s:
├── 每分钟调用: 2 次
├── 单次开销: ~0.5ms
└── 每分钟开销: ~1ms (0.002%)

使用场景 #

推荐使用默认值的场景 #

  • 生产环境: 大多数生产环境
  • 实时监控: 需要较实时的 JVM 信息
  • 标准应用: 正常的 Java 应用
  • 监控工具: 配合监控工具使用

推荐增加间隔的场景 #

  • 稳定系统: JVM 状况稳定
  • 减少开销: 希望减少系统调用
  • 长期运行: 长期运行的服务
  • 批量处理: 批处理类应用

推荐保持最小值的场景 #

  • 性能调优: 正在进行性能优化
  • 问题排查: 排查 JVM 相关问题
  • 监控密集: 需要密集监控
  • 测试环境: 测试环境使用

数据延迟分析 #

监控数据的延迟

refresh_interval = 1s (默认):
00:00.000 ──→ 堆内存 80%
00:00.500 ──→ 堆内存 85% (实际变化)
00:00.800 ──→ 查询 → 返回 80% (缓存)
00:01.001 ──→ 缓存刷新 → 获取到 85%
00:01.100 ──→ 查询 → 返回 85% ✅
延迟: 最多 1 秒


refresh_interval = 10s:
00:00.000 ──→ 堆内存 80%
00:00.500 ──→ 堆内存 85% (实际变化)
00:05.000 ──→ 查询 → 返回 80% (缓存)
00:10.001 ──→ 缓存刷新 → 获取到 85%
00:10.100 ──→ 查询 → 返回 85% ✅
延迟: 最多 10 秒

与 GC 监控的对比 #

两种刷新间隔的区别

monitor.jvm.refresh_interval:
├── 作用: JVM 基础统计信息
├── 内容: 内存、线程、类加载等
├── 触发: stats() 方法调用时检查
├── 默认: 1s
└── 文件: JvmService.java


monitor.jvm.gc.refresh_interval:
├── 作用: GC 专项监控
├── 内容: GC 时间、GC 开销、慢 GC
├── 触发: 定时任务自动执行
├── 默认: 1s
└── 文件: JvmGcMonitorService.java


独立工作:
├── 分别控制不同刷新逻辑
├── 可以独立配置
└── 互不影响

线程安全 #

并发访问的处理

public synchronized JvmStats stats() {
    if ((System.currentTimeMillis() - jvmStats.getTimestamp())
        > refreshInterval.millis()) {
        jvmStats = JvmStats.jvmStats();
    }
    return jvmStats;
}


synchronized 保证:
├── 线程安全
├── 不会重复获取
├── 数据一致性
└── 性能影响小


多个线程同时调用:
├── 线程1: 检查时间戳
├── 线程2: 等待锁
├── 线程1: 获取/返回数据
├── 线程2: 检查时间戳
└── 线程2: 返回缓存

注意事项 #

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

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

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

  4. 缓存机制: 使用缓存减少系统调用。

  5. 数据延迟: 数据有延迟,不是完全实时。

  6. 同步方法: 使用 synchronized 保证线程安全。

  7. 与 GC 监控区分: 与 GC 监控刷新间隔是独立的。

  8. 监控用途: 主要用于 API 和监控工具。

  9. 性能考虑: 刷新间隔越小,系统调用越多。

  10. 合理设置: 根据监控需求合理设置。

API 调用场景 #

stats() 方法的调用场景

1. Nodes Info API
   GET /_nodes/stats
   ├── 调用 stats()
   └── 返回 JVM 统计信息


2. CAT API
   GET /_cat/nodes
   GET /_cat/health
   ├── 调用 stats()
   └── 显示 JVM 信息


3. 监控工具
   ├── Prometheus Exporter
   ├── Metricbeat
   └── 其他监控工具
   ├── 定期调用 stats()
   └── 收集 JVM 指标


频繁调用时:
├── 缓存机制很重要
├── 避免重复获取数据
└── 降低性能开销