Java 和 PHP 应用程序的 GC 和内存行为？

Question

This question is regarding the Garbage collection behavior when request need more memory than allocated to Pod . If GC is not able to free memory, will it continue to run GC continuously or throw out of memory.

One pod contains java based app and another contain PHP based. In case of java xmx value is same as given to pod limit.

Answer 1

I can only talk about Java GC. (PHP's GC behavior will be different.)

If GC is not able to free memory, will it continue to run GC continuously after regular interval or throw out of memory.

It depends on the JVM options.

A JVM starts with an initial size for the heap and will expand it as required. However, it will only expand the heap up to a fixed maximum size. That maximum size is determined when the JVM starts from either an option ( -Xmx ) or default heap size rules. It can't be changed after startup.

As the heap space used gets close to the limit, the GC is likely to occur more and more frequently. The default behavior on a modern JVM is to monitor the %time spent doing garbage collection. If it exceeds a (configurable) threshold, then you will get an OOME with a message about the GC Overhead Threshold having been exceeded. This can happen even if there is enough space to "limp along" for a bit longer.

You can turn off the GC Overhead Limit stuff, but it is inadvisable.

The JVM will also throw an OOME if it simply doesn't have enough heap space after doing a full garbage collection.

Finally, a JVM will throw an OOME if it tries to grow the heap and the OS refuses to give it the memory it requested. This could happen because:

• the OS has run out of RAM
• the OS has run out of swap space
• the process has exceeded a ulimit , or
• the process group (container) has exceeded a container limit.

The JVM is only marginally aware of the memory available in its environment. On a bare metal OS or a VM under a hypervisor, the default heap size depends on the amount of RAM. On a bare metal OS, that is physical RAM. On a VM, it will be ... what ever the guest OS sees as its physical memory.

With Kubernetes, the memory available to an application is likely to be further limited by cgroups or similar. I understand that recent Java releases have tweaks that make them more suitable for running in containers. I think this means that they can use the cgroup memory limits rather than the physical memory size when calculating a default heap size.