> On Sep 18, 2019, at 11:05 AM, Severin Gehwolf <sgehw...@redhat.com> wrote: > > On Wed, 2019-09-18 at 10:15 -0700, Bob Vandette wrote: >> These internal methods were implemented in order to expose container metrics >> to >> via a public API. I’ve filed JDK-8203359 and JDK-8199944 to add an MBean >> and JFR events that will expose these values. >> >> JDK-8203359: Java Flight Recorder (JFR) improvements for containers >> JDK-8199944: Add Container MBean to JMX > > Sure. Has there been any movement on them?
I need to have a discussion with the core-libs team when I get back. I may pick up the JMX MBean work. This requires taking a look at other OS’s such as Windows to see what could be provided for that platform. Your cgroupv2 work is coming at a good time. > >> There are container tests that verify many of these methods. > > Like I said, I've run container tests with the patch below applied and > they seem to pass. So IMO they're not covered by tests. Grepping > through the code doesn't return anything either. > >> Can you give me a list of the metrics that are not available under >> cgroupv2? > > Not an exhaustive list, but from a cursory initial assessment: > > - public long getMemoryMaxUsage(); > - public long getKernelMemoryFailCount(); > - public long getKernelMemoryMaxUsage(); > - public long getKernelMemoryUsage(); > - public long getTcpMemoryFailCount(); > - public long getTcpMemoryMaxUsage(); > - public long getTcpMemoryUsage(); The Kernel and Tcp metrics are not that critical but I wish they had MemoryMaxUsage. That’s a useful metric for adjusting container memory limits. Bob. > > Thanks, > Severin > >> Bob. >> >> >>> On Sep 18, 2019, at 10:02 AM, Severin Gehwolf <sgehw...@redhat.com> wrote: >>> >>> Hi Bob, >>> >>> As you probably know, I'm looking at cgroups v2 support[0] in OpenJDK. >>> When looking at Metrics.java[1] I see that many methods aren't used >>> anywhere. Neither in tests nor in actual code. It looks like as if the >>> interface has been modelled along the lines of the cgroups v1 >>> implementation. These methods are: >>> >>> - public long getCpuUsage(); >>> - public long[] getPerCpuUsage(); >>> - public long getCpuUserUsage(); >>> - public long getCpuSystemUsage(); >>> - public double getCpuSetMemoryPressure(); >>> - public long getMemoryMaxUsage(); >>> - public long getMemoryUsage(); >>> - public long getKernelMemoryFailCount(); >>> - public long getKernelMemoryMaxUsage(); >>> - public long getKernelMemoryUsage(); >>> - public long getTcpMemoryFailCount(); >>> - public long getTcpMemoryMaxUsage(); >>> - public long getTcpMemoryUsage(); >>> - public long getBlkIOServiceCount(); >>> - public long getBlkIOServiced(); >>> >>> They are essentially dead code. Note that not all of them would have an >>> implementation in cgroups v2. With that in mind, does it actually make >>> sense for the Metrics interface to define those? We could keep the >>> implementations for cgroup v1 Metrics, but perhaps remove them from the >>> interface? It seems the current Metrics interface defines too many >>> methods for no good reason. Am I missing something? Thoughts? >>> >>> From the looks of it it wouldn't even require a CSR as >>> jdk.internal.platform isn't an exported package. >>> >>> Here is an example patch removing them, and jdk docker container tests >>> still pass: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8230305/remove_metrics_interface_methods.patch >>> >>> Thanks, >>> Severin >>> >>> [0] https://bugs.openjdk.java.net/browse/JDK-8230305 >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/377f47ccc20b/src/java.base/share/classes/jdk/internal/platform/Metrics.java >>> >
