Re: [Condor-users] greedy users

[Robert Futrick <rfutrick@xxxxxxxxxxxxxxxxxx>]

On Sat, Aug 15, 2009 at 8:54 AM, Mag Gam<magawake@xxxxxxxxx>; wrote:
> 20 jobs will be running the 10 will be in the queue.
> If I increase the quota to 25, and run "condor_restart -subsystem
> negotiator " 5 more jobs go in which sums to 25 jobs running.
> If I downgrade the quota back to 20, "condor_restart -subsystem
> negotiator ", when the next job finishes it should NOT sent any more
> jobs into the pool, but it does. So basically downgrading does not
> work.
>
Downgrading quotas does work, we use it in many environments. Try adding:
CLAIM_WORKLIFE = 1
to your execute node configuration 
(http://www.cs.wisc.edu/condor/manual/v7.2/3_3Configuration.html#17326), 
or alternately run:
condor_vacate_job Cluster.ProcToBeStopped

Condor performs match-making between submitters of jobs and execute 
slots to run jobs. Matches or claims between a scheduler and an execute 
node can run many jobs in order to minimize the amount of negotiation 
done to run jobs.  If claims between a scheduler and execute slot are 
valid when a job ends, the scheduler will give another job to the slot. 
Group quota affects the number of resource claims / matches for a given 
accounting group.  

In your case, I suspect the "Claim" between the scheduler and the 
execute machine is still valid when the job terminates, so the scheduler 
is giving the execute node more jobs. Setting CLAIM_WORKLIFE to 1 second 
will invalidate claims after a single job executes, as will running 
condor_vacate to vacate the slot.

At that point, your new, lower quota will kick-in.

> Another point:
> If i have 30 people in my physics department, it seems I can't set an
> individual's quota. For example, "Dale", "Bob", and "Sue" are in the
> physics group. I would like to give Dale max of 10 slots, Sue 20
> slots, Bob 25 slots.
>
> Any thoughts?

Give them their own accounting group: g_dale, g_bob, g_sue. However, it 
might be better to use fair-share within the group, so that "Sue" will 
take advantage of the processors when "Dale" is not using them.

Regards,
Rob

--

===================================
Rob Futrick
main: 888.292.5320

Cycle Computing, LLC
Leader in Condor Grid Solutions
Enterprise Condor Support and CycleServer Management Tools

http://www.cyclecomputing.com
http://www.cyclecloud.com



> On Mon, Aug 10, 2009 at 10:11 AM, Steven Timm<timm@xxxxxxxx>; wrote:
>> See the attached wrapper to condor_submit. what I
>> do is to add an +AccountingGroup=group_<gid>.user
>> where <gid> is equivalent to the unix gid of the user.
>>
>> I put this in place of condor_submit and move the real condor_submit
>> to condor_submit_real.
>>
>> Steve timm
>>
>>
>> On Sun, 9 Aug 2009, Mag Gam wrote:
>>
>>> Is there a way I can do "accountinggroup = somegroup.user"
>>> automatically and force users?
>>>
>>>
>>>
>>> On 8/6/09, Mag Gam <magawake@xxxxxxxxx>; wrote:
>>>>
>>>> thanks. I will look into this.
>>>>
>>>>
>>>>
>>>> On Thu, Aug 6, 2009 at 11:02 AM, Steven Timm<timm@xxxxxxxx>; wrote:
>>>>>
>>>>> You want to use group quotas.  Assign users to an accounting
>>>>> group and then they can only use X slots.  It can be a user-by-user
>>>>> group if necessary.
>>>>>
>>>>> By itself group accounting is voluntary but what I do is
>>>>> to put a wrapper around condor_submit to append the accountinggroup
>>>>> automatically to the classad.
>>>>>
>>>>> Steve Timm
>>>>>
>>>>>
>>>>> On Thu, 6 Aug 2009, Mag Gam wrote:
>>>>>
>>>>>> We have several of our PHD candidates who submit massive amounts of
>>>>>> jobs that clog our modeling grid. They submit close 400+ jobs
>>>>>> overnight on a grid which has only 3000 slots. I would like to ban
>>>>>> them but I can't do that  I too am a student. But, how can I set a
>>>>>> hard limit of 50 slots for these users? Btw, fair scheduling is
>>>>>> enabled but I would still like to put a hard limit. Any 
thoughts? Did
>>>>>> anyone else go thru this scenario? What did you do to fix it?
>>>>>> _______________________________________________
>>>>>> Condor-users mailing list
>>>>>> To unsubscribe, send a message to 
condor-users-request@xxxxxxxxxxx with
>>>>>> a
>>>>>> subject: Unsubscribe
>>>>>> You can also unsubscribe by visiting
>>>>>> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>>>>>
>>>>>> The archives can be found at:
>>>>>> https://lists.cs.wisc.edu/archive/condor-users/
>>>>>>
>>>>>
>>>>> --
>>>>> ------------------------------------------------------------------
>>>>> Steven C. Timm, Ph.D  (630) 840-8525
>>>>> timm@xxxxxxxx  http://home.fnal.gov/~timm/
>>>>> Fermilab Computing Division, Scientific Computing Facilities,
>>>>> Grid Facilities Department, FermiGrid Services Group, Assistant Group
>>>>> Leader.
>>>>> _______________________________________________
>>>>> Condor-users mailing list
>>>>> To unsubscribe, send a message to 
condor-users-request@xxxxxxxxxxx with
>>>>> a
>>>>> subject: Unsubscribe
>>>>> You can also unsubscribe by visiting
>>>>> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>>>>
>>>>> The archives can be found at:
>>>>> https://lists.cs.wisc.edu/archive/condor-users/
>>>>>
>>>>
>>> _______________________________________________
>>> Condor-users mailing list
>>> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx 
with a
>>> subject: Unsubscribe
>>> You can also unsubscribe by visiting
>>> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>>>
>>> The archives can be found at:
>>> https://lists.cs.wisc.edu/archive/condor-users/
>>>
>>
>> --
>> ------------------------------------------------------------------
>> Steven C. Timm, Ph.D  (630) 840-8525
>> timm@xxxxxxxx  http://home.fnal.gov/~timm/
>> Fermilab Computing Division, Scientific Computing Facilities,
>> Grid Facilities Department, FermiGrid Services Group, Assistant Group
>> Leader.
>>
>>
> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/condor-users/
>