-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 15.07.2014 um 15:46 schrieb William Hay:
> On Tue, 15 Jul 2014 12:15:30 +0000 > Taras Shapovalov <taras.shapova...@brightcomputing.com> wrote: > >> Hello, >> >> Do you know if it is possible to get a number of nodes that will be >> allocated for a parallel job if the job is in "qw" state? >> >> I see this number is calculated based on allocation_rule parameter, >> but also in some unclear (to me) cases one more node can be allocated >> for a master queue. In the majority of all other workload managers One additional remark: When do you get this information? I assume it was already fixed at submission time there too according to some allocation rule*, or is available in these cases only when the jobs have started too. In case you have to prepare something on the granted nodes, you can use a queue prolog (resp. epilog) and get the list of granted machine in $PE_HOSTFILE. - -- Reuti *) E.g. in Torque requesting "-l nodes=4:ppn=4" may get bunches of 4 several times per machine (there is a global setting to allow or disallow it). But only at runtime you get this information which nodes were finally selected. Hence you can't predict the number of machines if multiple allocations are allowed. > In general it is impossible to do this for a several reasons chief > amongst which are: > > i)Grid Engine doesn't allocate nodes but slots within queues on > the nodes. If you don't request exclusive access to the host (via an > appropriate resource) your job can be scattered all over the place. > > ii)You can request a range of slots so the number of slots (and > therefore nodes) the job will take up can vary. > > iii)Consumables are allocated per slot by default so the number of > slots you can fit on a node will vary with resource > requests/availabilty (this just adds a bit of maths to the problem but > the first two issues are enough to make the problem insoluble in the > general case). > > The job_is_first_task parameter on PEs controls how many SLAVE(qrsh) > sessions the job can launch: either as many as the slots allocated to > the job or one fewer. This is also reflected when the job is displayed > by qstat. AFAIK apart from the extra qrsh session it doesn't affect > resource allocation (unless you request a per job consumable I guess). > > With the above said our cluster at UCL has a JSV that: > i)Prevents the use of a range with a PE. > ii)Ensures jobs either fit on one node(requring a PE with a $pe_slots > allocation rule) or request exclusive access to nodes. > > That allows the JSV to calculate how many nodes/slots they will block > and enforce an appropriate policy. We then stuff the caculated blocked > slots value into the account string for later processing by our > reporting software. > > William > > > >> this parameter is possible to get before the job is started (that is >> useful sometimes), but I cannot find it in the both OGS and UGE. >> >> Thanks, >> Taras > > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPaLTMACgkQo/GbGkBRnRreBgCeLx9TwnfPwERefPw/AifTzDbp 0/kAoKIG3ueqdo5A/m46uP3DeFJQ7e2h =QMPH -----END PGP SIGNATURE----- _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
