Hi Bill, I have also set up a short queue in our company network, and I can confirm that it is quite easy. I am using a runtime limit of roughly one hour and the settings "those settings in "qconf -sq short.q":
s_rt 00:58:00 h_rt 00:59:00 In addition, I agree that queues are best not directly requested. Instead, I am using a complex value in the same queue definition: complex_values short=1 so that a user can request "qsub -l short=1 ..." to get into this queue. The complex is defined like this in "qconf -sc": #name shortcut type relop requestable consumable default urgency #------------------------------------------------------------------------------------------------ ... short short BOOL == FORCED NO FALSE 0 If no short request is done, the short queue will not be selected for the job. This is working great. Regards, Manfred Hi, Am 22.09.2015 um 00:21 schrieb Lane, William: > We're interested in implementing runtime limits on our queues, only because > it's become an issue. From my preliminary research it looks like the h_rt > resource limit is what will need to be specified for our short.q queue > definition. Yep, that's it. > I've tried googling for a FAQ to explain how to go about defining a queue > that limits the runtime of a job, but haven't had any luck. I'm guessing it's > not as easy as just specifying a complex h_rt value in the queue definition. It's that easy. > If a job is aborted due to exceeding h_rt, will a job-status email indicate > the reason why the job was aborted (i.e. if the job was submitted via qsub -m > a)? Not by default. You will have to use a mail wrapper which will scan the messages file of the exechost for an entry of this particular job and append it to the email. I can supply a snippet if you need. > Can someone point me to a FAQ on how to go about creating a queue definition > w/runtime job constraints? To avoid that other jobs end up in this queue, a job submission should specify the necessary h_rt value to avoid that any job not requesting h_rt might end up in the short queue. You can define a default in $SGE_ROOT/sge_request with "-l h_rt=infinity". With SGE it's best to request the necessary resources for your job and not to submit to any particular queue. Instead SGE will select an appropriate queue for the job. I.e. if you submit a job with "-l h_rt=600" it could still end up in an unlimited queue (as it fits into the limit). Neverthless it will be killed after 600 seconds, as it was specified during the job submission. -- Reuti > -Bill L. > IMPORTANT WARNING: This message is intended for the use of the person > or entity to which it is addressed and may contain information that is > privileged and confidential, the disclosure of which is governed by > applicable law. If the reader of this message is not the intended > recipient, or the employee or agent responsible for delivering it to > the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this information is strictly > prohibited. Thank you for your cooperation. > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users ________________________________ Dialog Semiconductor GmbH Neue Str. 95 D-73230 Kirchheim Managing Directors: Dr. Jalal Bagherli, Jean-Michel Richard Chairman of the Supervisory Board: Rich Beyer Commercial register: Amtsgericht Stuttgart: HRB 231181 UST-ID-Nr. DE 811121668 Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please consider the environment before printing this e-mail _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
