Red Hat Bugzilla – Bug 856564
[Scalability] Java process takes 11.9G of virtual space although it should be limited to 1G
Last modified: 2012-12-04 15:10:10 EST
Java process max virtural space is not defined so in my env it takes 11.9G of virtual space although it should be limited to 1G, that's because there is a typo in /usr/share/ovirt-engine/service/engine-service.py which defines the Xms again instead of Xmx:
"-Xms%s" % engineHeapMin,
"-Xms%s" % engineHeapMax,
The fix for the typo is here:
The fix for the typo has been merged upstream:
I have 2 quite loaded si20 envs, both are even more loaded than the original env, the VIRT size of the java process is 4871M and 5083M, this is much less than 11.9G but still above the max limit which is 1G.
Virtual size will always be larger than the size reserved for the HEAP (1G by default), as many other things go there, like stack threads, native code, mapped files, etc. What you should worry about is the resident set size (the RES column in top, or RSS in the output of ps). That is the real amount of RAM that the engine is using. It can be also higher than the max heap size, but will be usually much smaller than the virtual size.
To check that max heap size option is property configured you need other tools, like inspecting the command line (the -Xmx option should be there) or like jmap:
# jmap -heap pid_of_the_engine | grep MaxHeapSize
MaxHeapSize = 1073741824 (1024.0MB)
Here you see that the heap size is limited to 1G as expected.
The RES sizes in my envs are 1.4g and 1.6g.
BTW, I don't have the jmap rpm in my repos, but looks like a cool tool.
(In reply to comment #6)
> BTW, I don't have the jmap rpm in my repos, but looks like a cool tool.
It is part of the java-1.7.0-openjdk-devel (compiler, etc) package. That package is in the rhel-x86_64-server-optional-6 channel.