Opened 13 years ago
Last modified 10 years ago
#470 new enhancement
IZ2399: Add a qprobe command.
Reported by: | sgaure | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | sge | Version: | 6.1u2 |
Severity: | Keywords: | scheduling | |
Cc: |
Description
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2399]
Issue #: 2399 Platform: All Reporter: sgaure (sgaure) Component: gridengine OS: All Subcomponent: scheduling Version: 6.1u2 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: andreas (andreas) QA Contact: andreas URL: * Summary: Add a qprobe command. Status whiteboard: Attachments: Issue 2399 blocks: Votes for issue 2399: Opened: Fri Oct 12 17:17:00 -0700 2007 ------------------------ On our cluster we accept jobs from the cern-grid. The middleware there expects to be able to figure out how many slots are available for its use. We have wrapped qstat -xml for this and other purposes because our policies are quite complicated, so a qstat -g c doesn't tell the full picture. It is, I think, a general problem to figure out how many slots are available. But it has a not so difficult solution. It would be nice to have something like a qprobe command, which could tell me what would happen if I submit now. # qprobe -l whatever -P smth -t 60-200 -now y job would start on 73 slots or, more ambitious # qprobe -l whatever -P smth -t 60-200 -now n -R y 00:00:00: 73 slots 00:35:20: 85 slots 02:20:43: 120 slots 12:23:50: 200 slots or even report the full list of queue instances the job would run in. A simple version of qprobe could be implemented with a "dryrunjob" possibility in the scheduler, i.e. a job which isn't debited (or change the scheduler state in a material way), and the order is sent back to qprobe rather than used to start the job. This information is very hard to get at otherwise, because information about reservations are not easily available from the scheduler, and extracting all this from a full qstat (and qconf and rqs and stuff) requires duplicating most of the scheduling functionality. The timing can of course not be guaranteed, but it would at least provide a snapshot of what's going on right now. ------- Additional comments from sgaure Fri Oct 12 17:18:27 -0700 2007 ------- changed from 5.3 to 6.1
Note: See
TracTickets for help on using
tickets.