I think that the devel-...-xlong parameters being consumable is causing unforeseen behavior with the way that reservations are working. After some more testing and monitoring, I see that we're reaching our SLAs AND that larger parallel jobs are making it through the queue in a timely manner. What I saw were jobs whose only commonality was requesting, say, medium, and hence 128 processor parallel job bound for free node set X blocked a job bound for node set Y. Aside from a different strategy, all together, a complex that is requestable, consumable, but not reservable would solve this particular issue. Is that even possible?
-Brian On Thu, Aug 30, 2012 at 5:31 PM, Dave Love <d.l...@liverpool.ac.uk> wrote: > Brian Smith <b...@usf.edu> writes: > > > I have a mix of high-throughput and long wait jobs. We classify and > > prioritize jobs based on runtime. We use a jsv to set > > > > devel # job length < 1hr > > short # job length < 6hr > > medium # job length < 2day > > long # job length < 1wk > > xlong # job length > 1wk (goes to ACLed queue) > > [I'm surprised it's worth the trouble if there's the opportunity for > backfilling, but fine if so.] > > > 8.1.1 has been fantastic, overall, so this is a fairly minor issue; > > mostly me trying to eek out a couple more percentage points of > > utilization :) > > Glad it's useful, but it does sound as if there's a problem with the > reservation somehow from what you've described. > > -- > Community Grid Engine: http://arc.liv.ac.uk/SGE/ > -- Brian Smith Sr. System Administrator Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
