Kernel 2.6.32, OpenVZ + Java

[mva]

Hi,

Java has been a hot topic among OpenVZ users for years but here we go again. Has new Proxmox 2.6.32 kernel introduced yet any improvements running Java apps?

I did some tests on a OpenVZ container with 1024MB ram (+ swap 0):

java-test:~# free -m
             total       used       free     shared    buffers     cached
Mem:          1024         32        991          0          0          0
-/+ buffers/cache:        358        665
Swap:            0          0          0
java-test:~# cat /proc/user_beancounters | grep "privvmpages\|physpages\|oomguarpages"
            privvmpages                  8270               746396               262144               274644                   27
            physpages                    1480               209520                    0  9223372036854775807                    0
            oomguarpages                 1480               209520               262144  9223372036854775807                    0

Looks reasonable to me. Lets start a vanilla Tomcat 6.0 with jdk1.5.0_20, -Xms50m -Xmx200m:

java-test:~# free -m
             total       used       free     shared    buffers     cached
Mem:          1024        358        665          0          0          0
-/+ buffers/cache:        358        665
Swap:            0          0          0
java-test:~# cat /proc/user_beancounters | grep "privvmpages\|physpages\|oomguarpages"
            privvmpages                 91680               746396               262144               274644                   27
            physpages                    9015               209520                    0  9223372036854775807                    0
            oomguarpages                 9016               209520               262144  9223372036854775807                    0

358MB used?! Beancounter pages translated to MB are 91680~360MB, 9015~36MB. This means that my java process just reserved over 300MB ram, though some 30MB are actually used.

What if I change startup parameters to -Xms50m -Xmx500m:

java-test:~# free -m
             total       used       free     shared    buffers     cached
Mem:          1024        659        364          0          0          0
-/+ buffers/cache:        659        364
Swap:            0          0          0
java-test:~# cat /proc/user_beancounters | grep "privvmpages\|physpages\|oomguarpages"
            privvmpages                168825               746396               262144               274644                   28
            physpages                    9038               209520                    0  9223372036854775807                    0
            oomguarpages                 9038               209520               262144  9223372036854775807                    0

168825~660MB allocated, but still some 30MB actually used!

My conclusion after a few more tests is that Sun Java does allocate memory up to -Xmx instantly. This means for example that you'll have to reserve over a gig of memory to run 5 tiny java processes simultaneously in the same container.

How have you dealed with java+openvz? Of course a trivial solution would be just to let java take what it takes and live with it but I'm wondering would there be any more elegant solution than that?
I remember that kernels since 2.6.26 should have a improved memory controller which could also help openvz, but I might be wrong..

And btw. the very same tests with JRockit gave the kind of results I was expecting: Java allocated a minimum amount of memory on startup.

My Proxmox environment:

# pveversion  -v
pve-manager: 1.6-2 (pve-manager/1.6/5087)
running kernel: 2.6.32-3-pve
proxmox-ve-2.6.32: 1.6-12
pve-kernel-2.6.32-3-pve: 2.6.32-12
qemu-server: 1.1-18
pve-firmware: 1.0-6
libpve-storage-perl: 1.0-13
vncterm: 0.9-2
vzctl: 3.0.24-1pve3
vzdump: 1.2-7
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.12.5-1
ksm-control-daemon: 1.0-4

BR,
Mikael

 

[Lantizia]

Mikael,

In 2.6.27 the --swappages option was added, so 2.6.32 should have this option too. It fakes the idea of having real swap to the container - thus it's supposed to eliminate Java taking too much memory.

From what I've read in the wiki, the Proxmox VE GUI when it asks for Memory and Swap sizes... it (or rather pvectl) just adds them together and uses them for the vmguarpages/oomguarpages/privvmpages options.

However with the swappages option now available the swap we assign in the GUI can finally actually look like swap in the container, which should fix Java taking up too much memory - we shouldn't even need to fix how much memory it should be consuming.

Question is... does the GUI/pvectl use the swappages option or do we have to use it ourselves?

 

[mva]

Hello,

In 2.6.27 the --swappages option was added, so 2.6.32 should have this option too. It fakes the idea of having real swap to the container - thus it's supposed to eliminate Java taking too much memory.

Yes, --swappages is in 2.6.32. But unfortunately it seems to have no effect on how java behaves.

From what I've read in the wiki, the Proxmox VE GUI when it asks for Memory and Swap sizes... it (or rather pvectl) just adds them together and uses them for the vmguarpages/oomguarpages/privvmpages options.

Correct, mem+swap set in PVE GUI are summed up into ubc privvmpages (mem without swap set in lockedpages)

However with the swappages option now available the swap we assign in the GUI can finally actually look like swap in the container, which should fix Java taking up too much memory - we shouldn't even need to fix how much memory it should be consuming.

Question is... does the GUI/pvectl use the swappages option or do we have to use it ourselves?

Have you actually managed to restrict java memory consumption with swappages? My experiments show that it still reserves maximum heap size right away and does not honor -Xms at all. Atm, PVE does not use vzctl --swappages option.

 

[dietmar]

Question is... does the GUI/pvectl use the swappages option or do we have to use it ourselves?

No, sorry - i had no time to implement it so far. Any patches are highly appreciated ;-)