[GE users] Memory hard limit seems to be ignored on sge 5.3p5 version

Andreas Haas Andreas.Haas at Sun.COM
Tue Sep 14 13:08:58 BST 2004


On Tue, 14 Sep 2004, Andy Schwierskott wrote:

> Hi,
>
> >> You might look into "RESOURCE LIMITS" section of queue_conf(5) ;)
> >
> > this is the documentation, but not the behavior I observed. On LINUX at least
> > h_vmem will set the ulimits, all at once (only s_vmem/h_vmem in queue
> > definition set):
>
> Not sure if I understand this sentence? Do you mean that though you set only
> s_vmem/h_vmem you are seeing other limits limited as well?

Yep. There is a mechanism that uses h/s_vmem for computing
the minimum for other data size related limits as well. It's
also true that it is so far not documened in man pages, well
... I think we should blame Fritz ;)

But possibly it's a good occasion to actually reflect on it's
usefulness. Grid Engine users quite often have problems with
stack size limit set in an unexpected fashion resulting in
certain applications to fail. We've got that problem shortly
circumscribed in

   http://gridengine.sunsource.net/project/gridengine/howto/commonproblems.html

under "I can run my job script from ..". Possibly h/s_vmem
based minimum computation plays some role with those cases.

Andreas

>
> >
> > $ o tt.sh.o6207
> > core file size        (blocks, -c) unlimited
> > data seg size         (kbytes, -d) 512000
> > file size             (blocks, -f) unlimited
> > max locked memory     (kbytes, -l) unlimited
> > max memory size       (kbytes, -m) unlimited
> > open files                    (-n) 1024
> > pipe size          (512 bytes, -p) 8
> > stack size            (kbytes, -s) 512000
> > cpu time             (seconds, -t) unlimited
> > max user processes            (-u) 7168
> > virtual memory        (kbytes, -v) 512000
> >
> > core file size        (blocks, -c) unlimited
> > data seg size         (kbytes, -d) 512000
> > file size             (blocks, -f) unlimited
> > max locked memory     (kbytes, -l) unlimited
> > max memory size       (kbytes, -m) unlimited
> > open files                    (-n) 1024
> > pipe size          (512 bytes, -p) 8
> > stack size            (kbytes, -s) 512000
> > cpu time             (seconds, -t) unlimited
> > max user processes            (-u) 7168
> > virtual memory        (kbytes, -v) 512000
> >
> > In the source of setrlimits.c of the shepered:
> >
> > #  if defined(RLIMIT_VMEM)
> >   rlp.rlim_cur = s_vmem;
> >   rlp.rlim_max = h_vmem;
> >   pushlimit(RLIMIT_VMEM, &rlp, trace_rlimit);
> > #  elif defined(RLIMIT_AS)
> >   rlp.rlim_cur = s_vmem;
> >   rlp.rlim_max = h_vmem;
> >   pushlimit(RLIMIT_AS, &rlp, trace_rlimit);
> > #  endif
> >
> > Will SGE create any signals, when these limits are set anyway? I only had I
> > short look at the source, but I just saw for LINUX 64 bit limits are set if
> > TARGET32_BIT is defined. Is this OK? Please guide me, if I'm completely on the
> > wrong way.
>
> Linux from kernel 2.4 supports 64 bit limits.
>
> SGE does not create signals - the OS will (or will not) enforce the limits.
> E.g. typically SIGXCPU (cpu time limit exceeded) can be trapped by
> processes. Therefore SGE monitors the CPU usage of the whole job and kills
> the job once it exceeds its CPU time limit.
>
> Other limits (like mem sizes and number of open files) cannot be exceeded by
> the application - this not necessarily creates a signal. See setrlimit() man
> page on the respective OS what happens.
>
> Andy
>
>
> Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list