Java process snmp monitoring reports max values for Eden and Survivor Space are zero

Question

I'm monitoring a WildFly 10.1.0.Final Java process via SNMP port (configuring the com.sun.management.snmp properties) in a Linux box.

The problem is the reported max values for Eden and Survivor Spaces are zero.

.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"

The same monitoring script is used in a lot of other Java processes, which do not report this issue.

What can cause that? Cann these values be zero?

Best regards

Answer 1

The problem here is that jvmMemPoolMaxSize (OID .1.3.6.1.4.1.42.2.145.3.163.1.1.2.110.1.13) is defined in JVM-MANAGEMENT-MIB as type JvmUnsigned64TC, which seems kind of strange because Java specifically forbids the use of unsigned integer types.

The description for jvmMemPoolMaxSize implies that it's meant to represent the value returned by java.lang.management.MemoryPoolMXBean.getUsage().getMax(). The documentation for that method says "This method returns -1 if the maximum memory size is undefined."

The description of jvmMgmMIB addresses the issue with this explanation:

Where the Java programming language API uses long, or int, the MIB often uses the corresponding unsigned quantity - which is closer to the object semantics.

In those cases, it often happens that the -1 value that might be used by the API to indicate an unknown/unimplemented value cannot be used. Instead the MIB uses the value 0, which stricly speaking cannot be distinguished from a valid value. In many cases however, a running system will have non-zero values, so using 0 instead of -1 to indicate an unknown quantity does not lose any functionality.

I think it's safe to say this is one of the cases where a zero is not valid, so you should take it to mean that there is no defined maximum.