[GE users] qselect problem

Andreas Haas Andreas.Haas at Sun.COM
Sat May 8 10:36:05 BST 2004


I like this suggestion! A problem however might arises from
this in case qmaster is also not available due to maintainance
shutdown. Though qconf anyways returns immediately in case
qmaster is not available. But there is for sure an issue during
the phase of qmaster startup when the port is already bound
though, but requests are not yet processed and might be dropped.
Possibly the qconf request gets not lost, but in any case qconf
command could block for some time with the outcome of an exectuion
host boot-time delay ...

There could be differences wrts that behaviour between 5.3 and
6.0 due to the change in underlaying communication. In case of 6.0
the qping might be the right answer or starting qconf with an
ampersand.

Andreas


On Fri, 7 May 2004, Charu Chaubal wrote:

> Hi Kirk,
>
> There is one user who approaches this issue in a slightly different way:
> at the end of the rcsge script, he inserted a call to rcsge.local ---
> this is a script which sets machine-specific parameters as (fixed)
> resource values.
>
> This way, you can dynamically determine the resource values, but this
> only happens at boot time, since these values will not change after boot-up.
>
> (of course, you'd have to modify rcsge on all your exec hosts....).
>
> Regards,
> 	Charu
>
>
> Kirk Patton wrote:
> > On Wed, May 05, 2004 at 11:10:21AM +0200, Andreas Haas wrote:
> >
> >>Hi Kirk,
> >>
> >>the behaviour you encounter is the outcome of
> >>
> >>   AH-2004-03-04-1: Bugfix:    qselect/qstat -l selection wrongly considers
> >>                               load and utilization
> >>                    Issue:     771
> >>                    Bugtraq:   5019624
> >>                    Review:    AS
> >>
> >>the behaviour you possibly desire is a corresponding RFE #772. But why
> >>don't you specify immutable information such
> >
> >
> > The reason I used load sensors was that it is easier to set up.  Doing
> > it for each machine ment more administrative overhead for me.  The load
> > sensors look at the system and figure out what the correct value is.
> >
> > Reguarding #772, is that only for SGE 6.0 then?  I am running 5.3p6 and there
> > does not seem to be a "-full" option to qselect.  I rather like the old behavior.
> >
> > Kirk
> >
> >
> >
> >>   - os
> >>   - platform
> >>   - release
> >>   - ..
> >>
> >>in each hosts complex_values list? You can use the qconf -?attr
> >>switch family (use "exechost" as obj_nm) for efficiently accomplishing
> >>this.
> >>
> >>Using Grid Engine complex_values for non-mutable attributes has two
> >>fundamental benefits:
> >>
> >> (1) It lowers the amount of data that periodically needs to be
> >>     transfered from Execd to Qmaster and thus lowers effort
> >>     Qmaster on processing load reports.
> >>
> >> (2) It ensures this information is available even during
> >>     Execd maintainance shutdown. With load values a timeout
> >>     is in effect which causes them not be available after
> >>     a certain time when exec hosts queues change into
> >>     'unknown' state.
> >>
> >>The #771 fix changed the problematic behaviour of qstat/qselect
> >>returning a mutuable set of queues variying with the clusters
> >>load/utilization situation. Anyone please realize qselect be used
> >>within scripts for changing particular queue's configuation: If load
> >>values were generally considered by qselect it wouldn't be usable
> >>for this purpose. It's true that in versions prior 5.3 this behaved
> >>differently.
> >>
> >>Andy's and my take on this is that this is in fact is a bug since
> >>load/utilization were never considered in versions prior 5.3. Well,
> >>it's possible that users see this differently and we simly lack
> >>funded feedback from the Grid Engine users community.
> >>
> >>As pointed out by Rayson reverting the #771 fix does not require
> >>major development effort.
> >>
> >>RFC,
> >>Andreas
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> >>For additional commands, e-mail: users-help at gridengine.sunsource.net
> >>
> >
> >
>
>
> --
> ####################################################################
> # Charu V. Chaubal              # Phone: (650) 786-7672 (x87672)   #
> # Grid Computing Technologist   # Fax:   (650) 786-4591            #
> # Sun Microsystems, Inc.        # Email: charu.chaubal at sun.com     #
> ####################################################################
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list