I\'m running a containerized java application in Kubernetes.
In order to make the jvm reserve memory according to the container specifications, the flags -XX:+
Think about it this way, before that UseCGroupMemoryLimitForHeap
was added, you could specify Xmx
with a value larger than what your pod had (it would look only on the host memory, not the pod itself), eventually being killed. By default that was 1/4 of the memory if not specified. This happens because heap is calculated like:
heap = memory / MaxRAMFraction
And running:
java -XX:+PrintFlagsFinal | grep MaxRAMFraction
would reveal that MaxRAMFraction = 4
.
Now that UseCGroupMemoryLimitForHeap
was added, you can tell how much heap from the pod itself will be taken. By default, that is still 1/4; but you can adjust that via MaxRAMFraction
, of course.
If you specify both arguments, Xms
wins. always. And 1) this is pretty logic (as UseCGroupMemoryLimitForHeap
is more specific than Xmx
) 2) this is exactly proven by my experiments just now. No matter the order in which they are specified, Xmx
always wins.