JVM memory for Magnolia on Magnolia PaaS
Magnolia is a Java application running in a Java Virtual Machine (JVM) that consumes memory. You control the memory used by both the JVM and the Magnolia pod through the values you specify when deploying Magnolia with its Helm chart.
The JVM running Magnolia uses:
heap memory that the JVM periodically reclaims (garbage collection)
off heap memory needed to run the JVM for garbage collection, class storage, threading and other usage.
Too little heap memory can cause Magnolia to run more slowly because the JVM spends too much time in garbage collection or cause Magnolia to stop (and be restarted automatically) because it has insufficient memory.
For more on this, see Pods restarting.
Too little off heap memory can cause unexpected restarts of Magnolia due to "out of memory kills" by your Kubernetes cluster because the Magnolia pod has violated its memory limit.
How do I control the memory?
You control the memory used by the Magnolia instances and the JVM with the following Helm chart values:
The memory limits you set for the Magnolia pods (the
The maximum memory used for the JVM heap (the
The memory limit determines the overall memory (heap and off heap) available to the JVM. The
Allow several gigabytes for off heap memory use by the Magnolia JVM.
Magnolia can use off heap memory for:
Imaging operations (resizing, cropping, other image manipulation)
Compressing or uncompressing files
Publishing, especially when publishing large digital assets or doing recursive publications
The default values for
60 (percent) which should cover typical Magnolia projects given a large enough memory limit for the Magnolia pod. However, it can be difficult to predict how much off heap memory may be needed by Magnolia.
If Magnolia is "out of memory killed" by Kubernetes, you can either:
increase the memory limit for the Magnolia pod increasing both the heap and off heap memory available to Magnolia
maxPercentagevalue decreasing the heap memory and increasing off heap memory