Skip to content

Minor tweaks in the lab instructions #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ashish-k-s merged 1 commit into from
Oct 14, 2026
Merged

Minor tweaks in the lab instructions #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 11 additions & 7 deletions ...e-detection/pages/determining-cpu-availability-within-containers-openshift.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ oc new-project hotrod-s2i-project
oc new-app registry.access.redhat.com/ubi9/openjdk-17~https://github.com/alexbarbosa1989/hotrodspringboot.git --name=hotrod-app
----

NOTe: The deployment above (oc new-app`) does not set container limits, it will default to the host's limits. This directly impacts JVM heap allocation; for example, if the heap size exceeds 32 GB, Compressed Oops will automatically be disabled, and the Heap Address line will be omitted from the VM.info output.
NOTE: In the above deployment, `oc new-app` does not set container limits, it will default to the host's limits. This directly impacts JVM heap allocation; for example, if the heap size exceeds 32 GB, Compressed Oops will automatically be disabled, and the Heap Address line will be omitted from the VM.info output.

. Use the following command to check the status of the deployment:
+
Expand All @@ -26,6 +26,8 @@ oc get deployment
oc get pods
----
+
IMPORTANT: Wait for a few minutes until the build pod is completed and the application pod is running. You can use the `oc get pods` command to check the status of the pods.
+
Initially you will see the build pod running as follows.
+
----
Expand Down Expand Up @@ -131,10 +133,12 @@ active_processor_count: 2
sh-5.1$
----

Notes: Given the fact only integers can be used as CPU boundaries:
**Notes:** Given that CPU boundaries are expressed as integers in this lab, keep the following points in mind:

- Deployments created directly using `new-app` do not explicitly set CPU requests or limits. Consequently, they may run without CPU constraints unless defaults are applied by the cluster or namespace configuration.
- CPU values below 1 are effectively set to 1 CPU in this lab. This may be suitable for very small applications, such as Quarkus workloads, but is generally not recommended for enterprise applications. Limited CPU availability can constrain application threads and affect garbage collection (GC) behavior. In particular, the Serial GC may be more appropriate for workloads with limited CPU resources.
- Fractional CPU values are truncated, not rounded, when converted to integer CPU boundaries. For example, both 2200 millicores and 2950 millicores result in 2 CPUs.
- Java does not use CPU requests to determine its available processor count; it relies on CPU limits when container awareness is enabled and the runtime correctly detects the container's resource constraints.
- Java workloads can benefit from explicitly configured CPU and memory limits for more predictable resource usage and performance. See `unbounded deployment` for further details.


* Deployment straight with `new-app` does not set requests or limits, so it will come by default as unbounded deployment.
* Values below 1 CPU, are set at 1. That would be for very small applications like Quarkus. For Enterprise applications that's usually not recommended for several reasons, including the fact the SerialGC would be the most optimal GC for the deployments and the application's threads share very small CPU time.
* Fractional values are truncated, so 2200 millicores, becomes 2 CPU as well as 2950 milicores. Not rounded, but truncated.
* Java does not care about requests, only limits.
* Java workloads usually run best in performance given CPU and Memory limits for a series of reasons, see `unbouded deployment` for details.
14 changes: 7 additions & 7 deletions ...urce-detection/pages/determining-cpu-availability-within-containers-podman.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,9 +88,9 @@ INFO running in /deployments
2026-09-21 12:12:09.652 INFO 1 --- [ main] c.r.h.h.HotrodspringbootApplication : Started HotrodspringbootApplication in 59.731 seconds (JVM running for 61.304)
----
+
NOTE: The above command will not return back to the prompt. Otherwise, if you cannot open another terminal, run the command as background.
NOTE: The above command will not return back to the prompt. If you cannot open another terminal, run the command as background.

. Create a new terminal and follow the below steps in it.
. Create a new ssh session to the lab in another terminal and follow the below steps in it.

. Check the number of CPUs available on the host machine using the `nproc` command:
+
Expand Down Expand Up @@ -161,7 +161,7 @@ jcmd 1 VM.info | grep active_processor_count
+
----
[jboss@d24f38a138a2 ~]$ jcmd 1 VM.info | grep active_processor_count
active_processor_count: 8
active_processor_count: 2
----
+
NOTE: The output above shows that the application is using all the CPUS available on the host machine, which an unbouded deployment and not necessarily ideal for a microservice/containerized application. To limit the CPU usage, we will now deploy the application with CPU limits.
Expand All @@ -179,7 +179,7 @@ exit
----
podman rm -f <container-id>

podman run -p 8081:8080 --cpus="2" openjdk-hotrod:example
podman run -p 8081:8080 --cpus="1" openjdk-hotrod:example
----

. Follow the above steps again to connect to the running container and verify the CPU limits used by the application.
Expand All @@ -192,10 +192,10 @@ CONTAINER ID IMAGE COMMAND CR
[lab-user@bastion ~]$ podman exec -it 2f4ba2f67633 /bin/bash
[jboss@2f4ba2f67633 ~]$
[jboss@2f4ba2f67633 ~]$ jcmd 1 VM.info | grep active_processor_count
active_processor_count: 2
active_processor_count: 1
[jboss@2f4ba2f67633 ~]$
----
+
NOTE: The output above shows that the application is now using only 2 CPU, which is the limit we set for the container. This indicates that the application is container-aware therefore detects (and respects) the CPU limits set for its container.
NOTE: The output above shows that the application is now using only 1 CPU, which is the limit we set for the container. This indicates that the application is container-aware therefore detects (and respects) the CPU limits set for its container.

Finally, when executing the example above on the bastion example the max limite the bastion has is 2 CPUs.
IMPORTANT: **Never assign a single vCPU to a Java application in a production environment.** This lab uses a single vCPU only to demonstrate CPU limits for a Java process, due to resource constraints (the bastion host has only 2 CPUs). In production, allocate at least 2 vCPUs to every Java application to ensure sufficient CPU resources for execution.
Loading