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

Andy Schwierskott andy.schwierskott at sun.com
Tue Sep 14 11:53:36 BST 2004


Reuti,


On Tue, 14 Sep 2004, Reuti wrote:

> Andy,
>
>>> 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?
>
> correct, this is a 5.3p6 installation. If I do it from the command line, only
> -v is set. But from SGE, all three are set.

That's a good question. I assume the following:

    - data seg size cannot be bigger than virtual memory
    - stack size cannot be bigger than virtual memory
    - max user processes is a kernel limit (not set by SGE anyhow)
    - pipe size s a kernel limit (not set by SGE)
    - open files is a kernel limit

May be there's some logic in the shepherd which ensures that data and stack
size will not be set to higher values than virtual mem??


>>> $ 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.
>
> I know, I was wondering about the logic in the lines (now the 6.0 source):
>
> #if defined(IRIX) || (defined(LINUX) && defined(TARGET32_BIT))
>      ret = setrlimit64(resource, rlp);
> #else
>      ret = setrlimit(resource,rlp);
> #endif
>
> As I said, I only had a brief look at the source. When is TARGET32_BIT set?

If it's a 32bit kernel. On these OSes you may have a call to set 64 bit
limits (otherwise you couldn't e.g. set a file size limit > 2GB but less
than infinity.).

Andy


---------------------------------------------------------------------
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