From ebb52b18b7c3bda5334937740d00ad617260f862 Mon Sep 17 00:00:00 2001 From: Ashish shah Date: Thu, 17 Sep 2026 21:18:30 +0530 Subject: [PATCH] Lab review --- ...ng-cpu-availability-within-containers.adoc | 34 +++++++++++++++- ...-percentage-based-on-container-limits.adoc | 2 +- .../introduction-to-containerized-java.adoc | 2 +- ...its-and-requests-in-red-hat-openshift.adoc | 39 ++++++++++++++++--- ...-memory-in-containerized-environments.adoc | 3 +- .../pages/risks-and-memory-management.adoc | 1 + ...ainer-limits-and-resource-utilization.adoc | 1 + .../pages/java-diagnostics-jcmd.adoc | 1 + 8 files changed, 73 insertions(+), 10 deletions(-) diff --git a/modules/container-resource-detection/pages/determining-cpu-availability-within-containers.adoc b/modules/container-resource-detection/pages/determining-cpu-availability-within-containers.adoc index c7a0216..898166a 100644 --- a/modules/container-resource-detection/pages/determining-cpu-availability-within-containers.adoc +++ b/modules/container-resource-detection/pages/determining-cpu-availability-within-containers.adoc @@ -142,6 +142,38 @@ sh-5.3$ nproc 32 sh-5.3$ ---- - ++ NOTE: If you deploy a container with limits (not just requests, but limits) and `active_processor_count` (jcmd or java -XshowSettings:system) returns that limit, the application is correctly container-aware. Otherwise, in case it returns the host values, this indicates the application is likely not container aware (nproc shows host). + +. Set the resource limits on the deployment. ++ +[source,bash] +---- +oc set resources deployment/my-java-app --requests=cpu=100m --limits=cpu=200m +---- + +. Connect to the newly running container. ++ +[source,bash] +---- +oc get pods +oc rsh +---- + +. Verify the CPU limits honored by the container and the Java application running inside it. ++ +[source,bash] +---- +nproc +jcmd 1 VM.info | grep active_processor_count +---- ++ +Example output: +---- +sh-5.3$ nproc +1 +sh-5.3$ jcmd 1 VM.info | grep active_processor_count +active_processor_count: 1 +sh-5.3$ +---- diff --git a/modules/hands-on-lab/pages/tuning-java-heap-settings-percentage-based-on-container-limits.adoc b/modules/hands-on-lab/pages/tuning-java-heap-settings-percentage-based-on-container-limits.adoc index c4bf74a..fa71f02 100644 --- a/modules/hands-on-lab/pages/tuning-java-heap-settings-percentage-based-on-container-limits.adoc +++ b/modules/hands-on-lab/pages/tuning-java-heap-settings-percentage-based-on-container-limits.adoc @@ -53,7 +53,7 @@ Apply the following environment variables to your deployment: [source,bash] ---- oc set env deployment/ \ - JAVA_OPTIONS="-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0" + JAVA_TOOLS_OPTIONS="-XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0" ---- ### Step 3: Validate the Configuration diff --git a/modules/introduction-to-containerized-java/pages/introduction-to-containerized-java.adoc b/modules/introduction-to-containerized-java/pages/introduction-to-containerized-java.adoc index dbb39ec..6343fe7 100644 --- a/modules/introduction-to-containerized-java/pages/introduction-to-containerized-java.adoc +++ b/modules/introduction-to-containerized-java/pages/introduction-to-containerized-java.adoc @@ -12,4 +12,4 @@ Key aspects include: * **Cgroup Detection:** Leveraging kernel-level control groups to monitor and manage resource availability accurately. * **Operational Efficiency:** Simplifying deployments by ensuring the JVM aligns its internal memory and thread management with defined container resource limits. -This course is fully based on the current OpenJDK implementation and the article https://developers.redhat.com/articles/2024/03/14/how-use-java-container-awareness-openshift-4[How to use Java container awareness in OpenShift 4]. +This course is fully based on the current OpenJDK implementation and the article https://developers.redhat.com/articles/2024/03/14/how-use-java-container-awareness-openshift-4[How to use Java container awareness in OpenShift 4, window=_blank]. diff --git a/modules/openshift-and-kubernetes-integration/pages/configuring-limits-and-requests-in-red-hat-openshift.adoc b/modules/openshift-and-kubernetes-integration/pages/configuring-limits-and-requests-in-red-hat-openshift.adoc index 0d90b11..d06f236 100644 --- a/modules/openshift-and-kubernetes-integration/pages/configuring-limits-and-requests-in-red-hat-openshift.adoc +++ b/modules/openshift-and-kubernetes-integration/pages/configuring-limits-and-requests-in-red-hat-openshift.adoc @@ -72,11 +72,19 @@ kind: Deployment metadata: name: java-resource-demo spec: + + selector: + matchLabels: + app: java-resource-demo + template: + metadata: + labels: + app: java-resource-demo spec: containers: - - name: java-app - image: registry.access.redhat.com/openjdk/openjdk-11-rhel8 + - name: java-resource-demo + image: quay.io/hummingbird/openjdk:latest resources: requests: memory: "256Mi" @@ -97,10 +105,15 @@ oc rsh + [source,bash] ---- +# FIXME: The below file is not found in the container $ cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us # This will return 100000 (100ms), confirming the 1000m CPU limit. -$ jcmd VM.info -... +$ jcmd 1 VM.info | grep active_processor_count +---- ++ +Example Output: ++ +---- active_processor_count: 1 <-- shows 1 CPU ---- @@ -109,6 +122,20 @@ active_processor_count: 1 <-- shows 1 CPU [source,bash] ---- java -XshowSettings:vm -version -jcmd VM.info ---- -*Look for the output related to `MaxHeapSize` and `ActiveProcessorCount`. You will notice these values are derived from the limits, not the requests.* ++ +Example output: ++ +---- +VM settings: + Max. Heap Size (Estimated): 123.75M + Using VM: OpenJDK 64-Bit Server VM + +openjdk version "25.0.4.1" 2026-08-18 +OpenJDK Runtime Environment (Red_Hat-25.0.4.1.1-0) (build 25.0.4.1+1) +OpenJDK 64-Bit Server VM (Red_Hat-25.0.4.1.1-0) (build 25.0.4.1+1, mixed mode, sharing) +---- + +FIXME: Limit is set to 512Mi but the heap size displayed is 123.75M. Output contradicts the below explanation. + +*Look for the output related to `Max. Heap Size` and `active_processor_count`. You will notice these values are derived from the limits, not the requests.* diff --git a/modules/risks-and-memory-management/pages/managing-off-heap-memory-in-containerized-environments.adoc b/modules/risks-and-memory-management/pages/managing-off-heap-memory-in-containerized-environments.adoc index 7e03eb4..a3537fd 100644 --- a/modules/risks-and-memory-management/pages/managing-off-heap-memory-in-containerized-environments.adoc +++ b/modules/risks-and-memory-management/pages/managing-off-heap-memory-in-containerized-environments.adoc @@ -106,7 +106,7 @@ spec: image: quay.io/hummingbird/openjdk:latest env: - - name: JAVA_OPTS_APPEND + - name: JAVA_TOOL_OPTIONS value: "-XX:NativeMemoryTracking=summary" EOF ---- @@ -171,6 +171,7 @@ To ensure your configuration is resilient, verify that your application does not + [source,bash] ---- +## FIXME: The below path is not found in the container. cat /sys/fs/cgroup/memory/memory.limit_in_bytes ---- diff --git a/modules/risks-and-memory-management/pages/risks-and-memory-management.adoc b/modules/risks-and-memory-management/pages/risks-and-memory-management.adoc index 6ccae07..e33ff9c 100644 --- a/modules/risks-and-memory-management/pages/risks-and-memory-management.adoc +++ b/modules/risks-and-memory-management/pages/risks-and-memory-management.adoc @@ -10,6 +10,7 @@ When deploying Java in containerized environments, improper memory configuration * **Non-container aware allocation:** Allocating a certain percentage for container, but not benchmarking/tracking non-container aware components inside the Java application. For example, jemalloand glibc's malloc that are below the JVM and are both not container aware. **Best Practices:** + * Prioritize container-aware JVM settings over manual heap overrides to allow for dynamic scaling. * Benchmark application memory usage to determine the optimal ratio between heap and off-heap requirements. * Avoid configurations that ignore cgroup limits, as these bypass the self-tuning capabilities of modern JDKs. diff --git a/modules/troubleshooting-and-tooling/pages/analyzing-container-limits-and-resource-utilization.adoc b/modules/troubleshooting-and-tooling/pages/analyzing-container-limits-and-resource-utilization.adoc index 086a330..a111a1a 100644 --- a/modules/troubleshooting-and-tooling/pages/analyzing-container-limits-and-resource-utilization.adoc +++ b/modules/troubleshooting-and-tooling/pages/analyzing-container-limits-and-resource-utilization.adoc @@ -47,6 +47,7 @@ When analyzing resource constraints, follow these steps: * **Non-container-aware:** Avoid using legacy `top` or `free` commands inside the container, as they often report host-level data rather than container-constrained data. == Hands-on Activity: Inspecting JVM Resource Awareness +FIXME: This can be general instructions and not hands-on activity to be followed by learner. In this activity, you will verify if your currently running pod is correctly interpreting its cgroup limits. diff --git a/modules/troubleshooting-and-tooling/pages/java-diagnostics-jcmd.adoc b/modules/troubleshooting-and-tooling/pages/java-diagnostics-jcmd.adoc index 27c0058..a68f478 100644 --- a/modules/troubleshooting-and-tooling/pages/java-diagnostics-jcmd.adoc +++ b/modules/troubleshooting-and-tooling/pages/java-diagnostics-jcmd.adoc @@ -57,6 +57,7 @@ jcmd VM.native_memory summary 4. **Verification:** Compare the output of `GC.heap_info` against your pod's `resources.limits.memory` to verify if the JVM is respecting the container's memory boundaries. == Hands-on Lab: Inspecting JVM Resources +FIXME: Can this also be general instructions instead of hands-on activity? In this exercise, we will verify the JVM's memory awareness.