Hi Stu,
It would be nice if we can limit the number of jobs per user
natively. Otherwise, people who are using workflows can
dump few thousands of jobs to LRM through GRAM and overload
the machine. When something goes bad that leaves thousands
of jobs in a zombie state. I have not investigated the
exact reason for why that is happening.
For now, I think I will use the limits.conf to limit the
number of process per user. Thank you very much.
Prakashan
On 09/06/2011 07:31 AM, Stuart Martin wrote:
Hi Prakashan,
Is this for Fork only? For the LRMs, you can limit the number of jobs in the
queue (as well as other things).
If it for Fork, one thing VDT/OSG implemented for this was "managed fork".
https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/ManagedFork
http://vdt.cs.wisc.edu/releases/2.0.0/notes/Globus-ManagedFork-Setup.html
Basically, all "Fork" jobs go thru Condor. And Condor is configured to submit jobs to
the local/service host. Using this you get Fork functionality, but the ability to control/limit
the number of jobs per user. You could probably implement this managed fork concept with any of
the other LRMs too. E.g. configure a PBS queue and all "Fork" jobs go to the PBS queue
which run the jobs on the local/service host.
We have an issue for implementing this natively in GRAM, but have not gotten to
it yet:
http://jira.globus.org/browse/GRAM-4
Cheers,
Stu
On Sep 5, 2011, at Sep 5, 11:43 AM, Prakashan Korambath wrote:
Hi,
I was wondering whether there is a way to limit number of GRAM jobs submission
per userid in GT 5.04. One way I can think of is limiting in
/etc/security/limits.conf using Linux controls to limit processes per userid.
But if Globus has a way of controlling it that would be nice. Basically, we are
trying to limit number of runaway jobs. Thanks,
Regards,
Prakashan
