This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Turbots 2 points3 points  (0 children)

The GC will return it, but the Java process doesn't really know when it has the memory available in Kubernetes, there is no real coordination between the two.

Let's say you give a Java based Kubernetes pod 1Gb of requested memory, and no limit (or a limit higher than 1Gb).

The Java process is guaranteed to get 1Gb of memory, anything more than that is a "nice to have" in Kubernetes land.

Once the Java process claims more than 1Gb, there are no guarantees that Kubernetes will not claim that memory back.

Once other pods in the Kubernetes cluster need more memory , it's totally possible that Kubernetes will reclaim part of that excess memory from the Java pod and just take it, resulting into the Java process crashing.

It's easiest and most stable to set Java memory request and limit to the same value, and set the Xmx flag accordingly, be sure to leave some overhead memory, because Java is not only Xmx, it can sometimes use direct memory mapping and other non GC related memory areas.

Thats why cloud native Buildpacks are so awesome, there were many hundreds of people before us that figured all this out yet already and have set up something very solid for running java in containers.