RFC: jdk.PhysicalMemory vs. jdk.ContainerConfiguration expected behaviour?

[Erik Gahlin]

Hi Severin,

There should be some way to get the memory of the container host, but I'm not sure it should be stored in jdk.PhysicalMemory#totalSize.

It may make sense to normalize all event data to the same logical entity, regardless if it is physical, virtualized or containeried. I believe (but not sure) the CPU Load event shows 100% if all the cpu time is used in a container.

An alternative would be to add a field to the container events which specifies total memory of the host.

Erik
________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Severin Gehwolf <sgehwolf at redhat.com>
Sent: Thursday, November 10, 2022 2:56 PM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: RFC: jdk.PhysicalMemory vs. jdk.ContainerConfiguration expected behaviour?

Hi,

I've noticed that jdk.PhysicalMemory event reports the container memory
instead of the actual total memory of the container host. If one
compares 'memoryLimit' property of jdk.ContainerConfiguration events to
the 'totalSize' of jdk.PhysicalMemory event you'd notice that they're
the same inside a container. See [1].

As JFR is a monitoring tool it would be useful to get the hosts value
even inside a container via jdk.PhysicalMemory and the container value
via jdk.ContainerConfiguration (or some other event). If that was the
case, one could better reason about the actual system the app is
running on.

Would this make sense? Thoughts?

Thanks,
Severin

[1] https://bugs.openjdk.org/browse/JDK-8296671




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20221111/4f91b468/attachment-0001.htm>