OperatingSystemMXBean unaware of container memory limits

[Bob Vandette]

> On Jun 21, 2019, at 6:06 AM, Mario Torre <neugens.limasoftware at gmail.com> wrote:
> 
> The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data.
Correct.  We could file a separate bug to just correct the OS Bean but I was hoping to add access to the new Container Metrics information
at the same time.

> 
> I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think.
Yes.

> 
> Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that?

Fixing the existing OS Mbean is pretty straight forward.  Just have each method call the new Metrics API, check for error returns
in case this API is not supported on this platform and if success, return result, otherwise call existing logic.

Adding new OS access or a new Container Mbean is a bit more involved.

Since this is a public API, we’d need to take a look at at least one more OS (possibly Windows) and
decide which of the Metrics we want to expose.  I focused on Linux since this is the primary OS used
in container runtimes (even on Windows).  

Once you have the list of Metrics and Configuration data, Add a new Container MBean modeled
after the accessors in the Metrics API.

    jdk/open/src/java.base/share/classes/jdk/internal/platform/Metrics.java

You’d need to ensure proper javadocs are available and jtreg tests would need to be written to
validate the new APIs.

Bob.


> 
> Cheers,
> Mario
> 
> On Fri 21. Jun 2019 at 10:53, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi Bob,
> 
> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote:
> > Hi Andrew,
> > 
> > I am aware of the limitations of the OperatingSystemMXBean and was
> > hoping to address these limitations during the implementation of
> > https://bugs.openjdk.java.net/browse/JDK-8199944.
> > 
> > It would be helpful if you feel this is important to add some votes
> > to this issue.
> 
> It seems strange that the getAvailableProcessors() returns the
> container limit, while the memory limits are for the physical host. If
> anything, shouldn't they agree (both physical host or both container
> limits)?
> 
> When I briefly looked into it initially it seems to be a side-effect of
> what is being used by the JDK code implementation-wise. IIRC
> getAvailableProcessors() uses a runtime call. Memory reporting has it's
> own logic[1], thus not reporting the container limit.
> 
> This seems weird from a consistency perspective. Thoughts?
> 
> If I understand you correctly, you are arguing that container reporting
> should go into its own MX bean. On the other hand, CPU reporting for
> the OS MX bean is container aware already. That makes me believe we
> should rather make this consistent before evaluating a new MX bean.
> 
> Thanks,
> Severin
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365
> 
> 
> > Bob.
> > 
> > 
> > > On Jun 20, 2019, at 9:43 AM, Andrew Azores <aazores at redhat.com>
> > > wrote:
> > > 
> > > Hi all,
> > > 
> > > Apologies if this is not the most appropriate list, in which case
> > > please direct me where to go.
> > > 
> > > I've noticed a surprising result from the
> > > com.sun.management.OperatingSystemMXBean implementation when
> > > running in
> > > a containerized (specifically, using Docker on Linux) environment.
> > > The
> > > bean appears to be container-aware for processors, in that running
> > > with
> > > Docker option `--cpus 1.0` for example, on a multicore system, will
> > > cause both java.lang.Runtime#availableProcessors and
> > > java.lang.management.OperatingSystemMXBean#getAvailableProcessors /
> > > com.sun.management.OperatingSystemMXBean#getAvailableProcessors to
> > > return 1. However, the Docker option `--memory 100M` (or any other
> > > limit value) is not reflected in the value returned by
> > > com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize
> > > ,
> > > and instead the returned value is still the total physical memory
> > > of
> > > the host machine - of which only a small portion may actually be
> > > available to the "Operating System" of the JVM. Similarly for the
> > > methods regarding free physical memory, total swap, and free swap.
> > > 
> > > I have attached a patch which adds a small reproducer to the
> > > existing
> > > MemoryAwareness test.
> > > 
> > > This seems like a bug to me, since if the imposed container limit
> > > on
> > > processors as a resource is included as part of the "Operating
> > > System"
> > > resource reporting, then surely memory resources should be reported
> > > the
> > > same way. As I said, I found the current behaviour quite
> > > surprising.
> > > 
> > > -- 
> > > Andrew Azores
> > > Software Engineer, OpenJDK Team
> > > Red Hat
> > > <jdk-osmxbean-container-memory-test-01.patch>
> > 
> > 
> 
> -- 
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> 
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> 
> Please, support open standards:
> http://endsoftpatents.org/