Hi, Am 24.02.2011 um 20:18 schrieb Hung-Sheng Tsao (Lao Tsao 老曹) Ph. D.:
> since qacct -o uid will provide UTIME (cpu-time) of uid > could one setup consumable UTIME complex and load senser to tract the UTIME > when user's UTIME exceed the limit , system will set the fsare of uid to 0 so > uid cannot submit job? it's still possible to submit jobs. They just won't start. But: - you will need one resource per user. - the job's resource request (could be added by a JSV) will be subtracted from the complex definitinon, not the load sensor. So you would have to lower the complex's value inside SGE too. Or just use only a load sensor. But then you might face race conditions if two jobs are scheduled in the same scheduling interval. -- Reuti > regards > > > > On 2/24/2011 1:58 PM, Reuti wrote: >> Am 24.02.2011 um 18:53 schrieb Dave Love: >> >>> Reuti<[email protected]> writes: >>> >>>> Yep, there is nothing in SGE to withdraw the used computing time from some >>>> deposit. It would be possible with an external control instance, which >>>> issues: >>>> >>>> - `qacct` for the past usage. >>>> - `qstat -j "*"` to get the actual consumption for running jobs. >>>> - if the user is over his limit: put waiting jobs on system hold, and >>>> decide wether to drain (with some interest) / suspend / kill the just >>>> running ones. >>> As I understand it, Gold >>> <http://www.clusterresources.com/products/gold-allocation-manager.php> >>> does that sort of thing, but I don't know of any gridengine integration >>> for it -- does anyone else? >> AFAICS it seems possible to integrate in into SGE by putting the mandatory >> call to reserve the necessary fund for a job into the JSV and call "Job >> Quotation @ Job Submission Time", as there it no "submission_method" in SGE. >> In the a queue or global epilog the real costs could be adjusted by "Job >> Charge @ Job End Time". >> >> But I wonder about one thing: there is nothing in Gold to send commands to >> the queuing system. Means: you have no deposit, you can't submit (i.e. the >> deposit left will always allow the submitted job to run to their end) [using >> Reservations and adjusted to the real values at the end of the job in case >> the job was shorter than estimated]. Nevertheless, you can also have a look >> at the actual deposit which is left when this is updated priodically by a >> cron-job. >> >> Or you allow the submission even without te required fund, but place the job >> on systemhold and another cronjob (or the one from above), can remove the >> system hold in case the deposit which is left is sufficient again. >> >> The "Job Reservation @ Job Start Time" they suggest is not possible with >> SGE. It would have to be called when the job starts (or better: right before >> it starts) (yes, it could be put in a starter method or queue/global >> prolog). But when it fails, it would mean to reschedule the job as it's to >> late to prevent the job from running. There is no hook in SGE called by the >> scheduler just before it would try to start the job. It's the same problem >> like with the license manager integration. >> >> When you are happy with the reservation at submission time, it should work. >> >> PS: Pitfall: advance reservation in SGE. There is no ARV (advance >> reservation verifier). In my opinion the complete AR should be charged then >> - whether you submit something therein or not. But one could use `qrsub` >> with a wrapper and honor in the JSV when "-ar" is specified not to reserve >> again. `qrdel` would then call "Job Charge @ Job End Time" in a wrapper or >> when the AR ends at the intended time. >> >> -- Reuti >> _______________________________________________ >> users mailing list >> [email protected] >> https://gridengine.org/mailman/listinfo/users > <laotsao.vcf>_______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
