High Java memory assignment on Debian 9 containers

[Robert Worgul]

Hi everyone.

Something crucial seems to have happened in Debian 9. I first noticed this, when I upgraded one LXC container from Debian 8 to Debian 9. After the upgrade, my Java services consumed around ~20GB memory right after startup (if they weren't started with -Xmx). After some research how Java computes this initial heap memory value, I found that Java seems to somehow reference the memory values of the host machine, not the container.

This whole behavior seems to not be affected by a specific Java or Proxmox version. I did some tests with the default Debian 8 and 9 and Ubuntu 18.04 LXC templates, on our production Proxmox server (64 GB RAM) and on a freshly installed Proxmox inside of a Virtual Box VM (16 GB RAM). The Java versions differ from OpenJDK 7, 8, 10. I even tried Oracle Java in my earlier attempts (not in the screenshots), with exactly the same result. Every container has 1024 MB RAM and 512 MB Swap.

The attached screenshots are the results of my tests. The screenshots visualize, that as soon as the container is Debian 9 based, the memory sizes Java calculates explode. In the containers I did something like:

# install java somehow
apt update && apt install -y default-jre

#show the result
free -m && java -XX:+PrintFlagsFinal -version | grep -i heapsize | egrep 'Initial|Max'​

Could this be a bug in the hardware abstraction?


My tests:

1. cat /proc/meminfo on Debian 8 vs Debian 9
   
   
2. Default JRE on Debian 8 vs Debian 9
   
   
3. Same JRE version 8 on Debian 8 vs Debian 9
   
   
4. Debian 8 vs Ubuntu 18.04
   
   
5. Containers with the same specs on a freshly installed Proxmox VE (left to right: Debian 8, Java 8 -- Debian 9, Java 8 -- Ubuntu 18.04, Java 10)
   

 

[dietmar]

Some software uses syscalls to detect the hardware environment, and get fooled when they run inside containers. Such things must be fixed by that software itself. A workaround is to use a VM instead of a container.

 

[Robert Worgul]

Some software uses syscalls to detect the hardware environment, and get fooled when they run inside containers. Such things must be fixed by that software itself. A workaround is to use a VM instead of a container.

I highly doubt, that every Java version was changed with the release of Debian 9. Furthermore the Oracle Java binaries are exactly the same for both Debian versions.

My thoughts were just assumptions - not facts. Just a point to start the discussion from. It could be a kernel related thing or something with LXC, too.

Sadly using VMs instead of containers isn't really helping out. Especially not, if we aren't able to use Java on Linux containers in every future version.