OperatingSystemMXBean unaware of container memory limits

Bob Vandette bob.vandette at oracle.com
Thu Jun 20 14:16:00 UTC 2019


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

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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190620/a8c19dd3/attachment.html>


More information about the serviceability-dev mailing list