• Type: Enhancement
• Component: hotspot
• Sub-Component: jfr
• Affected Version: 11,12

• Priority: P3
• Status: Resolved
• Resolution: Fixed

• Submitted: 2018-05-17
• Updated: 2022-11-09
• Resolved: 2021-05-21

JDK 17
17 b24Fixed

Changeset: ee2651b9 Author: Jaroslav Bachorik <jbachorik@openjdk.org> Date: 2021-05-21 09:44:45 +0000 URL: https://git.openjdk.java.net/jdk/commit/ee2651b9e5a9ab468b4be73d43b8f643e9e92042 21-05-2021 FYI: the following test could be extended or used a template to test the ContainerConfiguration and ContainerUsage events: test/hotspot/jtreg/containers/docker/TestJFREvents.java 06-02-2020 Started working on a PoC comprised of two separate events: - Container Configuration - Container Resource Usage The rationale is that each additional data point we get for the container will increase the cost linearly (need to load a file from /proc fs and parse it) so we will gather that data only when definitely necessary. Eg. if the configuration event would be emitted once per chunk only we still would be getting pretty usable data. On the other hand, for resource usage we would perhaps want to have more frequent and periodic updates. Given the cost of each of these new event types the default setting would be to have only the configuration event enabled (if running on a containerized env). The resource usage event would be enabled only in 'profile.jfc'. 16-10-2019 I will reopen the RFE, and we will discuss it at RT Triage meeting. 23-09-2019 I don't believe this RFE should have been closed. There are additional Container metrics which are not covered by the existing JFR Events. Understanding the amount of physical memory (Current and Peak useage) that is being consumed by the container is critical in adjusting Kubernetes and Docker memory limits. There are other metrics such as memory failcount, per CPU user and kernel consumption that would be very useful. 23-09-2019 [~hirt] May be related to this bug: 8219999: JFR jdk.CPUInformation event reports incorrect information when running in Docker container 23-09-2019 Closing this umbrella issue because we investigated all the information necessary and found that the only problem is: "JDK-8219999 JFR jdk.CPUInformation event reports incorrect information when running in Docker container". 30-04-2019 [~hirt] To answer your questions: Q: ... was this for physical memory? A: The test case sets the --memory <MEMORY_VALUE> at container startup, records JFR event "jdk.PhysicalMemory", and asserts that the "totalSize" field matches the MEMORY_VALUE. Q: Also, have you considered adding events for the host to complement the ones for the container? Could you, please, give me clarification on your question? Do you mean: if running in a container, the events will report both values, the host-based and the container based. Is my understanding correct? 10-04-2019 Also, have you considered adding events for the host to complement the ones for the container? 09-04-2019 Hi Mikhailo! Regarding the testing of the reporting of memory, was this for the physical memory? 09-04-2019 I have created a test for Memory, CPU info and PID. The Memory data and PID work correctly, while number of CPUs seem to report data for host system, not the container. New test: 8219997: [TESTBUG] Create test for JFR events in Docker container: CPU, Memory and Process Info Filed a bug for CPU Info issue: 8219999: JFR jdk.CPUInformation event reports incorrect information when running in Docker container 01-03-2019 [~hirt]: Thank you Marcus for providing this info. I will reset the bug, so that we could re-triage it with this new information in mind. 28-11-2018 If you are looking to make JFR more "cloud friendly" - this is a very good place to start. 28-11-2018 The failure is in not separating host and container metrics. Most new loads are running in docker/kubernetes these days. This has been acknowledged through, for example, JDK-8203357/JDK-8182070. The same work needs to be done for JFR. So, as the title says: Create new events, and adjust existing events, to account for host/container reporting of resources 28-11-2018 From JFR Triage: [~hirt] Did you run this with JMC 7.0 ea against JDK 11 in docker environment and not crash? Did you see any major problems? Could you, please, be more specific about which failures you observe? 07-11-2018 Need initial investigation to identify specific issues and problem areas. 07-11-2018 Now that JDK-8203357 is completed, it would be very nice to get this one done. 06-11-2018