In the message dated: Wed, 29 Aug 2012 12:09:40 EDT,
The pithy ruminations from Brian Smith on
<Re: [gridengine users] Linux OOM killer oom_adj> were:
=> 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
We're seeing similar issues.
[The following is based on a fair amount of conjecture, some
googling, a bit of actually examining running processes, and
a lot of trial-and-error. Corrections and actual facts are
welcome.]
One consideration is that the problem with java may not actually be
in h_vmem, but in the stack setting. In the absence of java heap limits,
it appears that java tries to allocate memory based on the stack limit--if
that's not set via h_stack, then it is "unlimited". From java's point of
view, "unlimited" seems to be related to the amount of RAM. So, even if
a java program would run in, say 2GB, using "-l h_vmem=2G" alone seems to
result in java trying to use much more memory, as the heap is unlimited,
and then the memory limit imposed by SGE becomes the limiting factor.
Our current "solution" is a wrapper to the java executable that passes the
java arguments "-Xms" and "-Xmx" based on the current stack size (set via
"h_stack", which defaults here to 256M, but users can override). Note
that the "-X" options within are not standardized, and may vary by
different java versions.
In our environment, it's unusual to require a larger heap, but very common
to require a larger "h_vmem". It's difficult to determine the heap size,
but end users can find out the high memory use of a program fairly easily,
so they can set "h_vmem" as needed and most of the time the "-l h_stack"
value can be unchanged.
Mark
=>
=> -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
=>
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
