Java进程snmp监视报告Eden和Survivor空间的最大值为零

Question

我正在通过Linux中的SNMP (配置WildFly属性)监视一个com.sun.management.snmp 10.1.0。

问题是报告的最大值为、Eden、和幸存者空间为零。

.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.4 = Counter64: 775946240
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.10.4 = Counter64: 3946840064
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.12.4 = Counter64: 3774873600
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13.4 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.11.5 = Counter64: 4194304
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.10.5 = Counter64: 0
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.12.5 = Counter64: 4194304
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13.5 = Counter64: 0

.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.2 = STRING: "Metaspace"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.3 = STRING: "Compressed Class Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.4 = STRING: "G1 Eden Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.5 = STRING: "G1 Survivor Space"
.1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.2.6 = STRING: "G1 Old Gen"

在许多不报告此问题的其他Java进程中，都使用了相同的监视脚本。

是什么导致了这一切？这些值可以是零吗？

诚挚的问候

Answer 1

这里的问题是，jvmMemPoolMaxSize (OID .1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13)在JVM-管理-MIB中被定义为JvmUnsigned64TC类型，这似乎有点奇怪，因为JVM-管理-MIB专门禁止使用无符号整数类型。

对jvmMemPoolMaxSize的描述意味着它表示java.lang.management.MemoryPoolMXBean.getUsage().getMax()返回的值。该方法的文档表示“如果最大内存大小未定义，此方法将返回-1”。

对jvmMgmMIB的描述用这个解释解决了这个问题：

在Java编程语言API使用long或int的情况下，MIB通常使用相应的无符号数量--这更接近对象语义。 在这些情况下，API可能用来指示未知/未实现值的-1值通常不能使用。相反，MIB使用0，严格地说，不能将其与有效值区分开来。然而，在许多情况下，正在运行的系统将具有非零值，因此使用0而不是-1来指示未知的数量不会丢失任何功能。

我认为可以肯定地说，这是零无效的情况之一，所以你应该把它理解为没有定义的最大值。