配置项作用 #
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_interval | JVM 统计刷新间隔 | 1s |
monitor.jvm.gc.refresh_interval | GC 监控刷新间隔 | 1s |
monitor.jvm.gc.overhead.warn | GC 开销 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: 返回缓存
注意事项 #
默认值: 默认值为
1s,适合大多数场景。最小值: 最小值为
1s,不能设置更小。需要重启: 修改此配置需要重启节点。
缓存机制: 使用缓存减少系统调用。
数据延迟: 数据有延迟,不是完全实时。
同步方法: 使用 synchronized 保证线程安全。
与 GC 监控区分: 与 GC 监控刷新间隔是独立的。
监控用途: 主要用于 API 和监控工具。
性能考虑: 刷新间隔越小,系统调用越多。
合理设置: 根据监控需求合理设置。
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 指标
频繁调用时:
├── 缓存机制很重要
├── 避免重复获取数据
└── 降低性能开销





