Am 26.09.2015 um 23:25 schrieb Lane, William: >>> 2. >>> I was thinking of looking at the start time and end time, taking the >>> difference and seeing if this >>> difference is >= h_rt to determine if the job was aborted for this reason >>> or not. Then indicating >>> that in the subject header of the email. > >> Sure, that's also possible. But you have to scan the content of the to be >> send email to adjust the header. > > How does the script or executable referenced in the mailer line (modified via > qconf -mconf) get access > to the header
These are the positional parameters $1 $2 > or contents It's the stdin, therefore I use a subshell to combine the different parts which make up the new content (by using `cat` to insert the original message content). You can use a list of commands with curly braces too I think. > of the email sent by SGE? Are they environment variables? > >>> >>> 3. >>> I was hoping there might be some sort of formula to determine an ideal h_rt >>> value. I'll have >>> to kick this decision to management. >>> >>> Personally, I don't know how users are supposed to predict in advance how >>> long their jobs are supposed to >>> run for, nor how much memory their job will use via h_vmem. I've seen the >>> runtime for some jobs extend >>> to several days. > >> After submitting some jobs with unlimited runtime the users may get some >> experience about certain types of jobs. This would also allow backfilling >> then, in case they fit in a window where reserved >nodes would be idling >> otherwise. This can of course only work if you have an uniform cluster. >> Otherwise it would be necessary to specify different runtimes for different >> type of machines the jobs may >start on. > > Should the runtime limited nodes be the most computationally powerful > systems? Or the least powerful? > Should they exclude nodes that have large memory pools (i.e. lots of memory)? This all depends on your applications and observing their behavior to make these decisions. There is no setting which fits all sizes - otherwise many switches in SGE could simply be removed as there would be no need to tweak them to the actual requirements. Have a look at the runtime of the jobs, the time they have to wait, maybe even wait for machines which fits the memory requirements... -- Reuti > Thanks again Reuti. > 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 _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
