On 7/18/19 3:49 PM, David Holmes wrote:
Hi Andrew,
Sorry - this whole discussion slipped past me while I was traveling in
the US in late June (and have then been on vacation). As I just wrote
in the bug report:
There are two OperatingSystemMXBean interfaces:
- java.lang.management.OperatingSystemMXBean
- com.sun.management.OperatingSystemMXBean (a subtype of the former)
What the methods of these two interface report depends on exactly how
the method has been specified. If it refers to something "available to
the JVM (or current process)" then it needs to be container aware. If
it refers to the "whole system" or something "physical", then that
should report information for the whole system.
Arguably some of the whole-system/physical APIs are misguided and
reflect a history where containers and virtualized environments were
not envisaged. But changing them is a compatibility issue and so it
may be better to add new methods that report more interesting/relevant
information for the process's environment. Either way a CSR request
will need to be filed and the changes examined from a compatibility
perspective.
Agree.
When the APIs were introduced, it was defined for the whole system and
the spec should be made clear. If the APIs should be made
container-aware, the spec should be clarified of the new behavior.
Monitoring the whole system still provides a useful view even on a
container and virtualized environment. One idea to consider would be
to refactor com.sun.management.OperatingSystemMXBean and extract the
container-aware methods in a new MXBean which OSMXBean extends and
create one new singleton instance of the new MXBean to report
container-specific metrics.
Some of the APIs may not be "well formed" in the first place - for
example getSystemLoadAverage():
"Returns the system load average for the last minute. The system load
average is the sum of the number of runnable entities queued to the
available processors and the number of runnable entities running on
the available processors averaged over a period of time. "
This refers to the "system" but specifies the calculation is based on
"available processors" - which is a contradiction as "available" !=
"system".
The spec should be updated to "system" in this case.
So I think we need to take a step back at the moment and look at
exactly which methods can be container-aware based on their current
specification, and which should be container-aware but can't be
because of their current specification, and so what new methods may be
needed.
Bob's suggestion [1] to make the total/free physical memory and swap
space size container-aware sounds reasonable.
Refactoring c.s.m.OperatingSystemMXBean could be one option to explore.
Mandy
[1]
http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028710.html
