On Mon, Oct 26, 2015 at 02:22:19PM -0700, Skylar Thompson wrote:
Hi Mark,
IIRC maxvmem is a sampled value, so if the job experiences rapid
fluctuations in vmem usage, it might not be entirely accurate.
As you said, vmem is a polled value, and will change over time.
However, maxvmem should be a strictly non-decreasing value.
There were some versions of SGE (et al) where the vmem reporting was
invalid above 4G of RAM becuase a 32bit int was used for tracking this
value. I believe that all *current* versions of SGE derivatives (open
source and commercial) have this fixed.
We've worked around this a bit by using a release of GE (UGE in our case),
that supports cgroups, as the resident set size tends to not fluctuate
quite so much.
On Mon, Oct 26, 2015 at 05:11:23PM -0400, Michael Stauffer wrote:
SoGE 8.1.8
Hi,
I've been directing users to run qacct to look at completed jobs and check
the maxvmem field in order to set the memory limit requests (h_vmem &
s_vmem) when running similar jobs in the future.
But a couple users have seen maxvmem reported as a much lower value
reported than is needed for the job to run.
'man accounting' mentions the ACCT_RESERVED_USAGE paramter set in qconf.
'qconf -sconf' doesn't show this parameter at all, so can I assume it's
false, which means qacct's maxvmem should actually reflect the actual max
vmem usage? What might I be doing wrong or misunderstanding?
Thanks.
-M
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
--
-- Skylar Thompson ([email protected])
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
--
Jesse Becker (Contractor)
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
