[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] group <none> appeared after upgrade from 7.4.3 to 7.6.2
- Date: Wed, 19 Oct 2011 12:12:27 -0500
- From: Joe Boyd <boyd@xxxxxxxx>
- Subject: Re: [Condor-users] group <none> appeared after upgrade from 7.4.3 to 7.6.2
I think it's fine as long as you GROUP_DYNAMIC_MACH_CONSTRAINT to make sure the
quota calculations are getting the correct number of real slots for jobs.
There are certainly windows where the <none> group may get slots in front of the
admin defined groups (which I would argue is a bug) if your cluster has a bunch
of slots free (not many <none> jobs running so that starvation number is low)
but I don't think that matters much as it should pretty quickly catch up the
real groups if there are lots of free slots. It doesn't matter if the <none>
jobs get slots first if the real group quota jobs are going to get them in the
next few cycles. Once a cluster is full, it should work as desired.
On 10/19/2011 11:49 AM, Dan Bradley wrote:
Yes, priority factor only influences allocation of resources within a group.
As for how to configure priority factors: if you set GROUP_PRIO_FACTOR for all
other groups, I believe the default priority factory for users in the <none>
group can be set with DEFAULT_PRIO_FACTOR and/or REMOTE_PRIO_FACTOR, depending
on how ACCOUNTANT_LOCAL_DOMAIN is configured.
I agree that it is worth considering adding some mechanism to Condor whereby the
<none> group is considered last in the negotiation cycle. This would more
closely mimic the old behavior prior to 7.5.6. Of course, it may not always be
desired to starve the <none> group when there is contention for a subset of the
pool, so this would probably need to be a configurable option. Ugh ... more knobs.