Thanks Reuti, Skylar, Turns out it was a false alarm, sorry. The user hadn't told me they'd submitted to a different queue and I hadn't looked carefully enough to notice that. So now I'm not sure about the couple other times I've seen this in the past, it might have been something like that.
Skylar thanks for the qstat -w tip, I'll use that in the future. Reuti, if I were to adjust the setup not to use RQS, how would I limit users' resource usage? -M On Wed, Oct 19, 2016 at 7:37 AM, Reuti <re...@staff.uni-marburg.de> wrote: > Hi, > > > Am 19.10.2016 um 03:26 schrieb Michael Stauffer <mgsta...@gmail.com>: > > > > SoGE 8.1.8 > > > > Hi, > > > > I'm using consumables h_vmem, s_vmem and slots and have rqs's to manage > these. I've noticed sometimes that a user's jobs will sit in the queue even > though their qquota output shows they haven't hit their limits, and "qstat > -F h_vmem,s_vmem,slots" shows one or more nodes with enough resources > available to run one or more of the queued-and-waiting jobs. > > > > Tonight I tried modifying the queue on some qw'ed jobs using qalter. The > default queue is all.q, and first when I did 'qalter -q all.q <jobid>', the > waiting job starting running right away. I tried on some more waiting jobs > but no effect. Then I did 'qalter -q all.q@<host> <jobid>' where <host> > was a host that was reporting sufficient resources via qstat -F. The job > ran immediately. This worked for a few more jobs until resources were truly > insufficient. > > > > Does anyone have an idea what might be going on or how to continue > debugging? Thanks. > > I noticed such a behavior when RQS are in place. Can you adjust your setup > not to use RQS, or test it temporarily without them? > > -- Reuti > > > > > > -M > > _______________________________________________ > > users mailing list > > users@gridengine.org > > https://gridengine.org/mailman/listinfo/users > >
_______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
