[GE users] Share tree policy - not working 'fairly'

reuti reuti at staff.uni-marburg.de
Tue Nov 2 14:28:51 GMT 2010


Hi,

Am 02.11.2010 um 13:34 schrieb abrookfield:

> We have a share tree policy (Ticket Hierarchy is OSF)

here you can remove the functional policy having "OS" left.


> .  We have a few projects defined, including a DEFAULT project with contains the 'default' user node.  
> 
> We've got a few heavy users, some typical users, and some very light users.  
> userA is our heaviest user - 
> Level percentage 0.4%
> Total percentage 0.3%
> Actual resource share - 18%
> Targeted resource share 0.0%
> 
> userB is a typical user - 
> Level percentage 0.4%
> Total percentage 0.3%
> Actual resource share 0.5%
> Targeted resource share 0.0%
> 
> userC is a lightish user - 
> Level percentage 0.4%
> Total percentage 0.3%
> Actual resource share 0.1%
> Targeted resource share 0.0%
> 
> All three users have jobs waiting in the queue - here's a summary of the priorities/tickets assigned to the users
> 
> qstat -ext
> 
> 3082556 0.50005 0.00000 joba userA     DEFAULT        defaultdep qw                                   0     0     0     0     0 0.00                                     8        
> 3082578 0.50002 0.00000 jobb userB        DEFAULT        defaultdep qw                                   0     0     0     0     0 0.18                                     3        
> 3082625 0.50001 0.00000 jobc1 userC     DEFAULT        defaultdep qw                                   0     0     0     0     0 0.28                                     5        
> 3082626 0.50001 0.00000 jobc2 userC     DEFAULT        defaultdep qw                                   0     0     0     0     0 0.21                                     5        
> 3082627 0.50001 0.00000 jobc3 userC     DEFAULT        defaultdep qw                                   0     0     0     0     0 0.17                                     5        
> 3082643 0.50001 0.00000 jobc4 userC     DEFAULT        defaultdep qw                                   0     0     0     0     0 0.14                                     5        

Are these parallel jobs tigthly integrated?


> This doesn't seem very fair! userA is at the front of the queue because his job has been waiting the longest.  However given his past usage I'd like to see userB and userC bumped up the queue.
> So where are all our tickets assigned??  We've got quite a few users who just run computationally light interactive jobs - e.g.:

what's the value of:

$ qconf -ssconf
...
weight_waiting_time               1.000000

-- Reuti


> 3082632 0.55309 0.53086 INTERACTIV userD       DEFAULT        defaultdep r     0:00:00:01 0.02519 0.02320  2737     0     0     0  2737 0.14  interactive at node94     1   
> 
> Looks like nearly all of the 20000 share tickets are being awarded to the users running CPU-light interactive jobs who don't actually need them (interactive jobs should be scheduled immediately if resource is available, or fail).
> 
> To rub salt into the wound, of the few non-interactive jobs to be granted share tickets is a job from our friend userA:
> 
> 3080941 0.50075 0.00000 joba userA     DEFAULT        defaultdep r     80:10:14:04 4824892.15702 4988.52033     1     0     0     0     1 0.00  parallel at node32    16        
> 
> 
> Can anyone suggest if there's a better way to get the tickets shared between all the users, rather than having the distribution skewed towards the lightest users?  Or have the scheduler policy ignore interactive jobs?
> 
> Thanks,
> 
> Anthony.
> 
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=292123
> 
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=292149

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list