Calculate the MaxRAMPercentage dynamically

[NicklasWallgren]

The default MaxRAMPercentage is set to 80.0, but it doesn't take MaxMetaspaceSize or ReservedCodeCacheSize into consideration.

Wouldn't it be more effective to dynamically calculate the MaxRAMPercentage, factoring in GC_MAX_METASPACE_SIZE and possibly ReservedCodeCacheSize?

I manually patched the java-default-options to support dynamic calculation of MaxRAMPercentage, and we haven't experienced any OOMKilled incidents since implementing the change.

[jerboaa]

The point of us setting MaxRAMPercentage is that you get away with setting a better heap size (assuming 1 pod per app; that pod has a container memory limit) based on the detected container limit without needing to know the container limit.

The default MaxRAMPercentage is set to 80.0, but it doesn't take MaxMetaspaceSize or ReservedCodeCacheSize into consideration.

I take it you set the latter two, but not the heap size?

Note that you can override the default percentage to a different value or set the heap size in absolute terms. Have you considered using such an approach instead?

I manually patched the java-default-options to support dynamic calculation of MaxRAMPercentage, and we haven't experienced any OOMKilled incidents since implementing the change.

Glad that it works for you. I wonder how you calculate the dynamic percentage without knowing the total container memory. Note that there are other factors which need non-heap memory, not just the JIT and Metaspace (e.g. Thread stacks). So this gets complicated really fast.

[NicklasWallgren]

It gets complicated fast - we've mapped the resource.limit to an environment variable, which is then used in java-default-options to calculate a dynamic percentage.

However, at this stage, it might be more straightforward to use -Xmx directly instead of relying on MaxRAMPercentage.

Our current formula for MaxRAMPercentage is:
(Resource limit - (MaxMetaspaceSize + ReservedCodeCacheSize + Buffer (Threads))) / Resource limit.

It's somewhat unfortunate that the JVM cannot automatically determine the "optimal" memory allocation, even when MaxRAM is implicitly set. The situation is further complicated by k8s lack of a graceful mechanism for managing memory limits.

[jerboaa]

It gets complicated fast - we've mapped the resource.limit to an environment variable, which is then used in java-default-options to calculate a dynamic percentage.

That's a nice trick! We might be able to add support for something like that out of the box and do something sensible, but that's probably more a longer-term goal.