Bug 856564 - [Scalability] Java process takes 11.9G of virtual space although it should be limited to 1G
[Scalability] Java process takes 11.9G of virtual space although it should be...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Juan Hernández
Rami Vaknin
infra integration
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-12 06:37 EDT by Rami Vaknin
Modified: 2012-12-04 15:10 EST (History)
9 users (show)

See Also:
Fixed In Version: si19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 15:10:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rami Vaknin 2012-09-12 06:37:44 EDT
Version:
SI17

Description:

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,
Comment 1 Juan Hernández 2012-09-12 06:44:30 EDT
The fix for the typo is here:

http://gerrit.ovirt.org/7952
Comment 2 Juan Hernández 2012-09-12 07:44:30 EDT
The fix for the typo has been merged upstream:

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=651b9dcf4137f1b24188f0b333a7d18fb0c0a3b0
Comment 4 Rami Vaknin 2012-10-18 09:29:36 EDT
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.

Juan?
Comment 5 Juan Hernández 2012-10-18 09:54:19 EDT
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.
Comment 6 Rami Vaknin 2012-10-18 10:13:06 EDT
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.
Comment 7 Juan Hernández 2012-10-18 10:22:49 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.