Spike: Investigate using JVM features to manage container memory

Thanks. That seems completely reasonable to me.

there are two keys in the module descriptor that can communicate that kind of information to the external operators:

launchDescriptor/dockerArgs/HostConfig/Memory: Total memory allocation for the container
launchDescriptor/env: You can set the JAVA_OPTIONS environment variable as you see fit. For example, you could use MinRAMPercentage instead of MaxRAMPercentage if you felt that was more appropriate.

One rule of thumb proposed by , which seems sensible to me, is that you set the size for a single tenant with a standard workload, whatever that means to you, with the expectation that the operator will scale containers horizontally to meet higher demand. Like all rules of thumb, it probably won't work for every circumstance, but it seems a reasonable starting point.

Beyond that, you can of course communicate specific resource needs in the module README.

Does that address your concerns?

- Thanks for the confirmation.
- Thank you too for the expansion and yes it is.
I do however have another question and it's to do with the none-heap settings, Metaspace (which used to be called permgen) is always set to a high number (the maximum), which basically removes any upper limits. SO even though you've specified max ram that's only for Heap. Are there any plans/recommendations for us to incorporate that setting? Should as a developer just, set my max ram percentage for value in the memory section of the descriptor? How do external ops teams know that at 800Mb we can only have 50% for heap, but at 3GB you can allocate up to 90%?

is most likely referring to this error that occurs in the container log when using the old fabric8-based container:

cat: can't open '/sys/fs/cgroup/memory/memory.memsw.limit_in_bytes': No such file or directory

This specific error is generated when cgroup swap auditing is not enabled in the host kernel. This is default for recent Debian/Ubuntu kernels (it can be enabled via a kernel parameter). The old fabric8 base image had hooks for setting this control group, because it was originally written for Redhat/CentOS where cgroup swap auditing is enabled by default. At any rate, we are no longer using a base image based on fabric8 so this error should no longer appear. We do not set any container limitations on swap anyway - just RAM. Control group auditing for RAM is enforced.

also asked on https://folio-org.atlassian.net/browse/MODLIC-8#icft=MODLIC-8 "whether the CGroup is correctly available". Could you please explain how to verify that.