1

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

Jdamian
  • 3,015
  • 2
  • 17
  • 22

1 Answers1

2

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.

TallChuck
  • 1,725
  • 11
  • 28
  • Thank @TallChuck. But if the graph shown in [link](https://stackoverflow.com/questions/1262328/how-is-the-java-memory-pool-divided) is correct, the *Eden/Survivor* max space should be defined by `-XX:MaxNewSize`, which, in fact, is found in the command line arguments (`-XX:MaxNewSize=3584m`) of the Java process. In other words, the max value of that Memory Pool is defined, but it is reported as "no defined"... odd – Jdamian Mar 11 '22 at 11:04
  • From my first comment above, how can be the initial size (3,946,840,064 shown as .10.4) larger than the MaxNewSize set in the `-XX:MaxNewSize=3584m` (3,758,096,384 bytes)? – Jdamian Mar 11 '22 at 11:28
  • `MaxNewSize` apples to the "Young Generation", which contains the Eden and Survivor spaces, but it doesn't directly set the maximum size of those spaces. – TallChuck Mar 11 '22 at 14:21