[GE users] Process limits

Joe Landman landman at scalableinformatics.com
Sun May 20 21:00:14 BST 2007


    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

What is in your /etc/security/limits.conf ?

Are your /etc/profile.d/* tweaking the limits?  We had this issue for 
some infiniband stuff recently, and had to add in

*               soft    memlock	512
*               hard    memlock	1024

for the registration bits to work correctly (in limits.conf).  You might 
want to make some changes there, reboot a node to make sure it takes.

John Leidel wrote:
> Running SGE6.0u10 Suse Linux 10.0 on IA64
> 
> exec daemons are started via the standard sgeexecd init script.  They
> are running as `sgeadmin` rather than root.  
> 
> On Sun, 2007-05-20 at 15:50 -0400, Rayson Ho wrote:
>> Please provide SGE version (update level), OS version...
>>
>> Also, shepherd is started by execd... thus the shepherd can inherit
>> the limit from it. So, is the execd started by the rc scripts?? And,
>> is there a limit set there??
>>
>> Rayson
>>
>>
>>
>> On 5/20/07, John Leidel <john.leidel at gmail.com> wrote:
>>> All, a bit of a problem in our new SGE6 environment.  When users
>>> submit/run jobs, their process limits are arbitrarily set very low.  For
>>> example, the script :
>>>
>>> #!/bin/csh
>>>
>>> limit > /path/to/file.txt
>>>
>>> reports a cputime limit of 20:00
>>>
>>> cputime      20:00
>>> filesize     unlimited
>>> datasize     unlimited
>>> stacksize    unlimited
>>> coredumpsize 0 kbytes
>>> memoryuse    unlimited
>>> vmemoryuse   unlimited
>>> descriptors  1024
>>> memorylocked 128 kbytes
>>> maxproc      8192
>>>
>>>
>>> However, when one logs directly into the system, you get the
>>> following :
>>> cputime      unlimited
>>> filesize     unlimited
>>> datasize     unlimited
>>> stacksize    unlimited
>>> coredumpsize 0 kbytes
>>> memoryuse    unlimited
>>> vmemoryuse   unlimited
>>> descriptors  1024
>>> memorylocked 128 kbytes
>>> maxproc      8192
>>>
>>> The queue limits as follows :
>>> s_rt                  INFINITY
>>> h_rt                  INFINITY
>>> s_cpu                 INFINITY
>>> h_cpu                 10:00:00
>>> s_fsize               INFINITY
>>> h_fsize               INFINITY
>>> s_data                INFINITY
>>> h_data                INFINITY
>>> s_stack               INFINITY
>>> h_stack               INFINITY
>>> s_core                INFINITY
>>> h_core                INFINITY
>>> s_rss                 INFINITY
>>> h_rss                 INFINITY
>>> s_vmem                INFINITY
>>> h_vmem                INFINITY
>>>
>>> I've even tried specifying in the script to set the cputime to
>>> unlimited.  This also does not work.  So... something is setting the
>>> cputime ceiling for the shepherd's process tree.
>>>
>>> Any thoughts?
>>>
>>> cheers
>>> john
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web  : http://www.scalableinformatics.com
phone: +1 734 786 8423
fax  : +1 734 786 8452 or +1 866 888 3112
cell : +1 734 612 4615

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