Container-aware heap sizing for OpenJDK

[Ashutosh Mehra]

Hi Severin,


> So in that context the container limit would be detected from the
> cgroups filesystem.
>

That's correct. My question was actually targeting the mechanism used to
achieve A, not from within the JVM, but when deploying the containers.
As Jonathan clarified in another thread that this is done by
trial-and-error process. To quote his response,

"In general, container memory limit at Google is determined through a
trial-and-error process, where it takes into account all memory consumers.
We generally start with lower limits, and as traffic increases, increase
the limits. We also have some features that allow us to automatically come
up with estimates for these values based on the workloads."

Thanks,
Ashutosh Mehra


On Fri, Sep 16, 2022 at 11:36 AM Severin Gehwolf <sgehwolf at redhat.com>
wrote:

> On Fri, 2022-09-16 at 16:12 +0200, Thomas Schatzl wrote:
> >   * How is the container memory limit being determined? Does that
> > process take into account non-Java processes running in the container as
> > well? (Ashutosh Mehra)
>
> As this seems to be a re-curring question, I now wonder what the
> original proposal was...
>
> To me the proposal sounded like solving spurious Linux kernel OOM
> kills, while also reducing wasted (unused) memory within a container.
>
> So given a container limit of A, the heap gets "right-sized" based on
> A. Let X be maximum heap, let Y be non-heap memory. Y may be non-heap
> memory from a separate process or the JVM. What we want is to
> dynamically adjust X based on A-Y, no?
>
> My understanding was that A was pre-determined by the application
> deployment team, X and Y are the variables. The JVM detects the limit
> (A) in that container e.g. by code from JDK-8146115. Y is determined by
> the same code (OSContainer::memory_usage_in_bytes). X needs to tuned
> for reduced waste.
>
> So in that context the container limit would be detected from the
> cgroups filesystem.
>
> Did I get that part wrong?
>
> Thanks,
> Severin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220916/3b2d3ce8/attachment.htm>