OperatingSystemMXBean unaware of container memory limits

[Mario Torre]

Thanks!

Cheers,
Mario

On Fri 21. Jun 2019 at 15:54, Bob Vandette <bob.vandette at oracle.com> wrote:

> Here you go.
>
> https://bugs.openjdk.java.net/browse/JDK-8226575
>
> Thanks,
> Bob.
>
> On Jun 21, 2019, at 9:08 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi Bob,
>
> On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote:
>
> On Jun 21, 2019, at 4:22 AM, 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.
>
>
> You make a good point.  I’ll split the enhancement and add a bug to fix the
> current MX Bean since this is pretty easy to do.
>
>
> Sounds great! Please let me know once the OS MX bean bug has been
> created. I'll then assign it to myself and help Andrew through the
> process of getting it fixed.
>
> Thanks,
> Severin
>
> Bob.
>
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190621/ef01b4cd/attachment-0001.html>