[Mauiusers] fairshare and backfill

Steve Young chemadm at hamilton.edu
Thu Feb 7 07:35:25 MST 2008


Hi Bas,
	Thanks for the reply! I was beginning to wonder if I was the only  
person on this list ;-).  I had tried to do a maxproc and/or maxmem  
on my classes. However, it just didn't seem to work well. If no one  
else was using the cluster, capping a user off at a certain amount of  
processors while the rest of the processors remain idle didn't seem  
to be making the cluster efficient at utilizing all the resources. If  
lets say a user (A) met that maxproc/maxmem limit and was still able  
to have jobs backfilled after that would seem to me a good way to  
solve my problem. This way I could guarantee them a certain amount of  
processors while allowing over that limit to be backfilled thus  
making the cluster efficient by utilizing all the resources possible.  
If another user (B) were to submit, the same thing should happen for  
them. The first user's (A) backfilled jobs would get pre-empted to  
run the second users jobs up to the maxproc limit and then backfill  
the rest. However, with maui, when you hit your limit your done. No  
other jobs will get backfilled to run.
	So while that didn't seem to work out as I'd like I thought it would  
be great if fairshare could be calculated based on the number of  
users on the queue. If there are 2 users, then 1 / 2 users would give  
them each 50% fairshare. If there were 4 users, then fairshare would  
get calculated as 1 / 4 users giving them each 25% fairshare. I'm  
sure there are drawback to this as well.
	Basically, all I want to do is give each user a fairshare of  
resources while still running as many jobs as possible in order to  
keep the utilization close to 100%. Especially when there are jobs in  
the Q state. It doesn't seem to make sense to cap everyone at a  
certain limit and queue the rest of their jobs while resources sit idle.
	I've struggled with trying to solve this situation for quite a while  
now. This kind of surprises me as I don't think what I'd like to see  
happen is something out of the ordinary. Isn't this what most  
clusters want to achieve?

"Give everyone a fair share of resources while maintaining close to  
100% utilization of those resources"

To me this would seem to be the next logical step up from running  
your cluster as a simple FIFO queue.

On another note I am confused by setting a default of 25% fairshare  
for everyone. If you have less than 4 people using the system then  
your going to have idle resources. Then when you exceed 4 people  
utilizing the cluster what happens to fairshare then?  Does maui  
start setting fairshare equally to each user up to 25%? Let say you  
have 5 users. Does fairshare try to keep everyone at 20%? Or does it  
give the first four 25% and the fifth have to wait for some of the  
first four's jobs to complete?

Again, thanks for the reply =). I hope to hear more from other sites  
about how they accomplished this.

-Steve


On Feb 7, 2008, at 3:14 AM, Bas van der Vlies wrote:

>
> On Feb 6, 2008, at 9:55 PM, Steve Young wrote:
>
>> Hi,
>>         Ok I guess this is my 3rd and last attempt to ask how to  
>> do this.
>> All I would really like is to know how to make a person's fairshare =
>> 1 / <number of users who have submitted jobs>
>> With a fairshare like this it would seem like then everyone would get
>> an equal amount of resources.
>>
>> Aside from running as a FIFO scheduler this would seem to be the next
>> step for most. Allowing anyone to run any number of jobs but assuring
>> that each user gets an equal fairshare of resources. This example
>> would fit nicely in the Appendix "Case Studies" in the maui admin
>> manual. I'd be happy to help put a case study together to show this
>> if someone could help explain how to do it =). Thanks,
>>
>> -Steve
>>
>>
> Steve,
>
>   I do not know if this answer your question.  When for eg a user  
> has a fairshare of 25% and he has used all of it. He gets a  
> negative priority. You can set in the maui.cfg to:
>  http://www.clusterresources.com/products/maui/docs/ 
> a.fparameters.shtml#rejectnegpriojobs
>
>
> what we have done is every user has a MAXPS for eg 600 hours, now  
> he can run:
>   * 100 jobs for 6 hours
>   * or 10 jobs for 60 hours
>  * ...
>
> This is another solution that a user does not monopolize the  
> system.  It also very dynamic when a user submits 11 jobs with a  
> walltime of 60 hours. The system will schedule 10 jobs and after 6  
> hours the 11th job can run, because 10 * 6 = 60 hours are   
> reallocated to the user's MAXPS
>
> At our site we use MAXPS and FAIRSHARE to balance the system and  
> preventing users to monopolize the system.
>
> Regards
>
>>
>>
>>
>> On Jan 31, 2008, at 12:18 PM, Steve Young wrote:
>>
>>> Hi,
>>>       So perhaps my first question didn't make any sense ;-).  
>>> Basically,
>>> I am trying to figure out how to prevent a user from tying up all
>>> the resources by submitting a large amount of jobs to the queue. If
>>> no one else has requested any resources then as many jobs that can
>>> run should. However, if someone else submits jobs I'd like for them
>>> to get their fair-share of resources without having to wait for the
>>> first users jobs to complete and free up resources.
>>>       Perhaps, I've answered my question with "fairshare" and  
>>> should be
>>> looking more closely at that. What I don't understand is if I were
>>> to set a fairshare of lets say 25% per user, how would this effect
>>> the queue system if no one else was running jobs. Essentially, I'd
>>> want this user to get 100% of the resources until someone else were
>>> to submit. Here is the policy I'd like to simulate:
>>>
>>> A user is guaranteed  up to 32cpu's or 32Gb of ram. Above that,
>>> jobs will get backfilled. Backfilled jobs will get suspended as
>>> more users utilize the queue.
>>>
>>> Perhaps, I have this all wrong and should be thinking about it
>>> differently. I'd love to see some examples of what others have done
>>> to remedy this situation. Thanks in advance,
>>>
>>> -Steve
>>>
>>>
>>>
>>> On Jan 28, 2008, at 2:55 PM, Steve Young wrote:
>>>
>>>> Hi,
>>>>      I am trying to figure out how to make the following work  
>>>> within
>>>> our cluster using torque/maui:
>>>>
>>>>
>>>> I'd like a user to be able to submit as many jobs as they like.
>>>> However, they should only be allowed up to 32cpu or 32gb of
>>>> memory. After that if there are idle resources then the rest of
>>>> their jobs can be backfilled on idle nodes.
>>>>
>>>> If another user submits jobs they should get the same policy and
>>>> pre-empt any backfilled jobs (if that's required to meet the 32cpu
>>>> or memory limit).
>>>>
>>>> So basically, I think this should be fairly common. I want to run
>>>> as many jobs as possible on idle resources but only guarantee the
>>>> jobs that fall under the MAXPROC/MAXMEM policy. I've implemented
>>>> the MAXPROC/MAXMEM policy but it appears backfill won't work for
>>>> the remaining jobs. So I am assuming backfill has to abide by the
>>>> MAXPROC/MAXMEM policy I have in place. Can anyone give me some
>>>> pointers to the proper way to implement this? Thanks in advance!
>>>>
>>>> -Steve
>>>>
>>>>
>>>> [root@ maui]# cat maui.cfg (edited for some content)
>>>> # maui.cfg 3.2.6p14
>>>>
>>>>
>>>> # Resource Manager Definition
>>>>
>>>> RMCFG[JAKE] TYPE=PBS
>>>>
>>>>
>>>> RMPOLLINTERVAL        00:00:30
>>>>
>>>> SERVERPORT            42559
>>>> SERVERMODE            NORMAL
>>>>
>>>> # Admin: http://clusterresources.com/mauidocs/a.esecurity.html
>>>>
>>>>
>>>> LOGDIR                /var/log/maui
>>>> LOGFILE               maui.log
>>>> LOGFILEMAXSIZE        100000000
>>>> #LOGLEVEL              3
>>>> LOGLEVEL              2
>>>> LOGFILEROLLDEPTH      5
>>>> STATDIR               /var/log/maui/stats
>>>> SERVERHOMEDIR         /usr/maui/
>>>> TOOLSDIR              /usr/maui/tools/
>>>> LOGDIR                /var/log/maui/
>>>> STATDIR               /usr/maui/stats/
>>>> #LOCKFILE              /usr/maui/maui.pid
>>>> SERVERCONFIGFILE      /usr/maui/maui.cfg
>>>> CHECKPOINTFILE        /var/log/maui/maui.ck
>>>>
>>>> # Misc configs
>>>>
>>>> ENABLEMULTINODEJOBS     TRUE
>>>> JOBMAXOVERRUN           00:01:00
>>>> #SYSTEMDEFAULTJOBWALLTIME       1:00:00:00
>>>> USEMACHINESPEED         ON
>>>> #PREEMPTPOLICY          CHECKPOINT
>>>> PREEMPTPOLICY           SUSPEND
>>>> CREDWEIGHT             1
>>>> CLASSWEIGHT            1
>>>> QOSWEIGHT              1
>>>> RESCTLPOLICY            ANY
>>>>
>>>> # Job Priority: http://clusterresources.com/mauidocs/
>>>> 5.1jobprioritization.html
>>>>
>>>> QUEUETIMEWEIGHT       1
>>>>
>>>> # FairShare: http://clusterresources.com/mauidocs/6.3fairshare.html
>>>>
>>>> FSPOLICY              DEDICATEDPS
>>>> FSDEPTH               7
>>>> FSINTERVAL            86400
>>>> FSDECAY               0.80
>>>>
>>>> # Throttling Policies: http://clusterresources.com/mauidocs/
>>>> 6.2throttlingpolicies.html
>>>>
>>>> # NONE SPECIFIED
>>>>
>>>> # Backfill: http://clusterresources.com/mauidocs/8.2backfill.html
>>>>
>>>> BACKFILLPOLICY        BESTFIT
>>>> RESERVATIONPOLICY     CURRENTHIGHEST
>>>> #RESERVATIONPOLICY    NEVER
>>>> RESERVATIONDEPTH      50
>>>> RESDEPTH              32
>>>>
>>>> # Node Allocation: http://clusterresources.com/mauidocs/
>>>> 5.2nodeallocation.html
>>>>
>>>> NODEACCESSPOLICY        SHARED
>>>> #NODEALLOCATIONPOLICY   MINRESOURCE
>>>> #NODEALLOCATIONPOLICY   MAXBALANCE
>>>> NODEALLOCATIONPOLICY    FASTEST
>>>> #NODEAVAILABILITYPOLICY         UTILIZED
>>>> NODEAVAILABILITYPOLICY  COMBINED
>>>> NODEMAXLOAD             1.0
>>>> NODELOADPOLICY          ADJUSTSTATE
>>>>
>>>>
>>>> # QOS: http://clusterresources.com/mauidocs/7.3qos.html
>>>>
>>>>
>>>> QOSCFG[qm] PRIORITY=100 QFLAGS=PREEMPTEE
>>>> QOSCFG[md] PRIORITY=100 QFLAGS=PREEMPTEE
>>>> QOSCFG[faculty] PRIORITY=1000 QFLAGS=PREEMPTOR
>>>> QOSFEATURES[qm] hamilton g03
>>>> QOSFEATURES[md] hamilton
>>>>
>>>> # Standing Reservations: http://clusterresources.com/mauidocs/
>>>> 7.1.3standingreservations.html
>>>>
>>>> # SRSTARTTIME[test] 8:00:00
>>>> # SRENDTIME[test]   17:00:00
>>>> # SRDAYS[test]      MON TUE WED THU FRI
>>>> # SRTASKCOUNT[test] 20
>>>> # SRMAXTIME[test]   0:30:00
>>>>
>>>> # Creds: http://clusterresources.com/mauidocs/
>>>> 6.1fairnessoverview.html
>>>>
>>>> # USERCFG[DEFAULT]      FSTARGET=25.0
>>>> # USERCFG[john]         PRIORITY=100  FSTARGET=10.0-
>>>> # GROUPCFG[staff]       PRIORITY=1000 QLIST=hi:low QDEF=hi
>>>> #
>>>> # Groups
>>>> #
>>>> GROUPCFG[faculty]       PRIORITY=1000 QLIST=faculty QDEF=faculty
>>>> GROUPCFG[hamilton]      PRIORITY=10
>>>> GROUPCFG[users]         PRIORITY=10
>>>> #
>>>> # Classes (queue's)
>>>> #
>>>> #CLASSCFG[main]         QLIST=md:qm
>>>> CLASSCFG[main]          QLIST=md:qm:mercury MAXPROC=32,64
>>>> MAXMEM=32768,65536
>>>> CLASSCFG[hamilton]      QLIST=md:qm
>>>>
>>>>
>>>>
>>>> torque config
>>>> -------------------
>>>>
>>>> [root@ maui]# qmgr
>>>> Max open servers: 4
>>>> Qmgr: print server
>>>> #
>>>> # Create queues and set their attributes.
>>>> #
>>>> #
>>>> # Create and define queue main
>>>> #
>>>> create queue main
>>>> set queue main queue_type = Execution
>>>> set queue main Priority = 100
>>>> set queue main resources_default.neednodes = main
>>>> set queue main resources_default.walltime = 24:00:00
>>>> set queue main enabled = True
>>>> set queue main started = True
>>>> #
>>>> # Create and define queue hamilton
>>>> #
>>>> create queue hamilton
>>>> set queue hamilton queue_type = Execution
>>>> set queue hamilton resources_default.neednodes = hamilton
>>>> set queue hamilton resources_default.walltime = 24:00:00
>>>> set queue hamilton enabled = True
>>>> set queue hamilton started = True
>>>> #
>>>> # Set server attributes.
>>>> #
>>>> set server scheduling = True
>>>> set server default_queue = main
>>>> set server log_events = 511
>>>> set server mail_from = adm
>>>> set server query_other_jobs = True
>>>> set server resources_default.ncpus = 1
>>>> set server resources_default.walltime = 24:00:00
>>>> set server scheduler_iteration = 60
>>>> set server node_check_rate = 150
>>>> set server tcp_timeout = 6
>>>> set server job_nanny = True
>>>> _______________________________________________
>>>> mauiusers mailing list
>>>> mauiusers at supercluster.org
>>>> http://www.supercluster.org/mailman/listinfo/mauiusers
>>>
>>> _______________________________________________
>>> mauiusers mailing list
>>> mauiusers at supercluster.org
>>> http://www.supercluster.org/mailman/listinfo/mauiusers
>>
>> _______________________________________________
>> mauiusers mailing list
>> mauiusers at supercluster.org
>> http://www.supercluster.org/mailman/listinfo/mauiusers
>
> --
> Bas van der Vlies
> basv at sara.nl
>
>
>



More information about the mauiusers mailing list