Disable Processor Counting based on Cgroups Container Support
ioi.lam at oracle.com
ioi.lam at oracle.com
Wed May 17 23:35:31 UTC 2023
On 5/12/23 10:18 AM, Bruno Borges wrote:
> Hi folks,
>
> Looking at the source code, I couldn't identify a way (on tip, or any
> previous release) to keep container support for memory limit, but
> disable it for CPU limit.
>
Do you mean you want the app to use as much CPU as available, but
somehow constrain it so that it will not starve the other apps on the
same host of CPU time?
I think this can be done by running your containers with CPU shares but
without CPU limits.
We had a bug in interpreting CPU shares such that the JVM will
under-utilize CPUs when CPU shares have been set. This has been fixed in
https://bugs.openjdk.org/browse/JDK-8281571. Could you check if your JDK
has this fix?
Thanks
- Ioi
> While I could achieve this by not setting a CPU limit in my container
> orchestration solution (e.g., Kubernetes), it wouldn't necessarily
> give me what I am looking for: I do want to set a CPU limit at the
> container level, but I want the JVM to count for all processors in the
> host/node. While I can manually tweak this by modifying
> -XX:ActiveProcessorCount, this requires me to know upfront how many
> processors the Node/Host will have.
>
> Additionally, setting -XX:ActiveProcessorCount=-1 does not give me the
> behavior I was expecting either.
>
> The reason I raise this is due to the new In-place Pod Resource
> Resizing feature in Kubernetes 1.27, that allows a pod to change the
> CPU limit without restarting the pod. See this article for details:
> https://medium.com/@karla.saur/trying-out-the-new-in-place-pod-resource-resizing-68a0b3c42b72
>
> In an ideal world, the JVM would dynamically scale its thread pools,
> GC threads, and other components at JVM and Application level
> accordingly, but we are not there yet, I believe.
>
> I'd love to hear what others think.
>
> Thanks,
> Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20230517/7cb3effd/attachment.htm>
More information about the hotspot-runtime-dev
mailing list