On Mon, 11 Jul 2022 09:30:59 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> It's not clear that introducing this as a standard API is the right thing to >> do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", >> "CPU period", "soft limit" etc. will last the test of time and that we don't >> be back here next year with another PR to deprecate or replace this API? I >> don't disagree that exposing a MXBean could be useful for >> monitoring/management purposes but I think we have to be cautious getting >> getting locked in. A possible starting point for prototyping purposes and >> getting feedback is a JDK-specific MXBean (module jdk.management). > >> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only >> available on Linux systems.I do not know the process of creating a CSR, can >> you help me create a CSR > > It's too early to think about a CSR, probably a bit premature to create a PR > too because it will take a few iterations to come to agreement on what API to > expose, if any. > > I don't think this should be a standard API, meaning > java.management/java.lang.management.ContainerMXBean is not the right place > for this. A JDK-specific MXBean is an option but it would only be usable on > Linux and maybe only usable when running in a container environment. Working > down, it's not clear to me how stable the attributes are and the mapping to > both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which > already defines the "TotalSwapSpaceSize" attribute. There's another level of > detail beyond that with unusual value -2 to distinguish "not available" from > "not supported". So I think there are a few things to think about there. > > Another direction to think about is not exposing an API that you can compile > against but instead just register a MBean that provides access to the > attributes that are interesting for the container environment. By this I mean > ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be > enough to browse the MBean and its attributes in any JMX console and may give > you a bit more flexibility to expose attributes that are specific to the > cgroup version. I'm not saying this is the right direction, I'm just listing > it here as something that could be explored. If the main use case is JMX > consoles rather than programmatic access then it may not be too bad. > @AlanBateman OperatingSystemMXBean makes the CPU and Memory related > information for a process available regardless of whether that process is > running in a native operating system environment or a containerized > environment. It does not provide container configuration information such as > its provider (crgoups v1 or v2), CPU shares, CPU quota etc, which can be > useful for monitoring and troubleshooting purposes. Yes, I know this but I think there is a lot more thought required before deciding to augment this with another API for the container environment. There are a couple of things to explore. ------------- PR: https://git.openjdk.org/jdk/pull/9372
