I stopped bothering with vmem and looked at RSS instead (if I'm not swapping... which I shouldn't be... it tends to work). The JVM seems to "claim" a large amount of virtual memory for its heap, but most often does not actually need to use it. There are options you can pass the JVM that also help to reduce the vmem claim:

-mx{N}   # maximum memory for JVM

where {N} are some integer in bytes.

You can use the Xms and Xmx options to reduce the amount of memory the JVM can gobble up, which seems to help. Mind you, this limits the heap size that your java app can utilize, so you have to make sure you application will live within those bounds comfortably. You could probably do something like

...
# pad about 64mb from h_vmem to allow for shepherd, shell, etc.
extraSpace=((64*1024*1024))
mem=$(qstat -j $JOB_ID | egrep -o 'h_vmem=[0-9]+' | cut -d'=' -f2)
((mem-=extraSpace))

java -mx${mem} myClass
...

This stackoverflow piece seems to cover it nicely: http://stackoverflow.com/questions/7412619/what-are-the-advantages-of-specifiying-memory-limit-of-java-virtual-machine



-Brian

Brian Smith
Sr. System Administrator
Research Computing, University of South Florida
4202 E. Fowler Ave. SVC4010
Office Phone: +1 813 974-1467
Organization URL: http://rc.usf.edu

On 08/30/2012 08:20 AM, Peter van Heusden wrote:
Sorry, I just saw that my response to you was off list.

In my experience, even giving java 4G (-l h_vmem=4G) isn't enough for
all but the most trivial jobs. Somehow java seems to size its memory
requests based on total available system memory and I have to allocate
ridiculous amounts of RAM to satisfy it. What tweaks do you use to make
java jobs run successfully?

Thanks,
Peter

On 08/29/2012 06:28 PM, Ian Kaufman wrote:
We found h_vmem to be highly unpredictable, especially with java-based
applications.  Stack settings were screwed up, certain applications wouldn't
launch (segfaults), and hard limits were hard to determine for things like
MPI applications.  When your master has to launch 1024 MPI sub-tasks (qrsh),
it generally eats up more VMEM than the slave tasks do.  It was just hard to
get right.


Sadly, my users are using Java as well. Java and HPC do not mix very
well, especially on 64 bit systems where a JVM will consume at least
4GB of RAM by default without mucking with any flags. Additionally,
the crew I work with use a workflow/job management tool that isn't
thread aware, so every child Java app that gets launched gets its own
JVM. That is high on the list of things to fix!

Ian


_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@gridengine.org
https://gridengine.org/mailman/listinfo/users

Reply via email to