Just re-read this and I must apologise for the grammer and spelling.
Let me add another observation. In a well ordered shop it is usually a
programmer or operator that is hogging the system. Running something in
a session that should be done in batch. An operator doing a
store/restore from a session will do it everytime. A programmer running
a "quick" report or QUERY FIND ALL, REPORT with SORT will not only
knock back the batch jobs, but also impact all the legitimate on-line
processes. Once you have found the culprit an education session,
followed by a course in manners accompanied by a big stick should
resolve your problems without resorting to changing the queues.
Sometimes that does not work. We had one programmer who never used
batch and selfishly ignored the impact on other users. The solution was
simple. Everyday we used GLANCE to knock his session back to the DQ and
left him there. This went on for a year and he never found out and we
never had a problem with him hogging the system.
Regards
John
>
> Need to exercise some care when playing with the
> queues.
> I took over a unix shop once and discovered that all
> the application
> users were running under superuser. Why asks me? So
> we can issue a
> "nice" to increase their priority when they log on
> says they. It turned
> out that in their efforts to improve the performance
> of some of the
> background processes they had increased the
> priorities of the
> background process, that had effected the
> performance of the on-line
> users, so they increased their priority. All of this
> using a -ve nice
> factor, which required superuser. Overall
> performance had deteriorated.
> I was surprised that anthing still worked as the
> users had a higher
> priority than some of the OS functions.
>
> I would suggest that there is something in the CQ
> that should not be
> there. Use GLANCE or something to find some resource
> hoggers that are
> running in the CQ and then implement some system
> wide procedure to have
> that process demoted.
> The EQ is a forgotten Q that can be used here.
> Sessions go into the CQ
> and batch jobs default to the DQ and those queue
> settings are usually
> good enough. The EQ is usually set below the DQ, but
> generally unused.
> There is no reason why you can't change the EQ
> sttings to run between
> CQ and DQ. You can then demote the offending CQ
> process to the EQ or
> promote some essential DQ jobs to the EQ.
> I have been in sites where QUERY is run through a
> command file that
> when run in a session demoted it to a lower Q so as
> not to interfere
> with the other on-line users. I had a site where we
> had a batch server
> process that we always ran in a promoted EQ so that
> it saw more action
> than the other batch processes that ran in the
> default DQ.
>
> But first, check your existing queue settings to
> ensure that someone
> has not been experimenting before you.
>
> Regards
> John
>
> --- Jeff Kell <[log in to unmask]> wrote:
> > martin knott wrote:
> > > I had a probelm the other day in which none of
> my
> > jobs (submitted in
> > > the D queue) were advancing at all. The users'
> > sessions (in the C
> > > queue) didn't report any drop in perfromance at
> > all. If a job was
> > > 'promoted' to the 'C' queue, it ran through ok.
> > >
> > > Does anyone have not-to-technical explanation of
> > how the queues work
> > > together, and possibly an explanation for what
> was
> > happening?
> >
> > I looked ahead and nobody has touched on this one
> > yet, so I'll take
> > my shot...
> >
> > This can't be explained without a basic
> "reference",
> > the best one
> > being the tail end of a :SHOWQ listing.  The
> default
> > values are:
> >
> > >                     ------QUANTUM-------
> > > QUEUE  BASE  LIMIT  MIN    MAX    ACTUAL  BOOST
> > TIMESLICE
> > > -----  ----  -----  ---    ---    ------  -----
> > ---------
> > >  CQ    152    200   1      2000   8       DECAY
> > 200
> > >  DQ    202    238   2000   2000   2000    DECAY
> > 200
> > >  EQ    240    253   2000   2000   2000    DECAY
> > 200
> >
> > Process scheduling is handled by the MPE
> Dispatcher.
> >  Every process in
> > the system is classified (simplistically) into
> > either "DORMANT" or
> > "RUNNING" columns in :SHOWQ output.  Dormant
> > processes are those which
> > are waiting on something (terminal read, disc I/O,
> > database lock, etc)
> > while those Running are ready to execute.  They
> may
> > not all actually
> > be "running" - you can only be running as many
> > processes at the same
> > time as you have processors.  But the remaining
> > processes in the running
> > list are "eligible to run".
> >
> > Processes that are running will continue to run
> > until:
> >
> > a)  They do something that makes them wait (issue
> a
> > terminal read, or
> >     a disk I/O, etc), or
> > b)  They exceed their "quantum" of CPU time, in
> > which case the
> >     dispatcher takes over and interrupts them.
> >
> > The second case does not apply to system processes
> > scheduled linearly
> > and some priv-mode exceptions, but let's keep this
> > simple.
> >
> > When the CPU is "available" through the conditions
> > above, the dispatcher
> > must decide which process to launch next.  If
> there
> > are no
> > processes in the running list, it simply suspends
> > until some process
> > is ready to go.  Otherwise, the process with the
> > lowest priority
> > number is selected.
> >
> > Now, on to how the "numbers" are assigned.  From
> the
> > :SHOWQ trailer
> > you can see that CQ covers 152-200, DQ 202-238,
> and
> > EQ 240-253.  So,
> > in answer to your original question, as long as
> > there is a process in
> > the CQ ready to run, nothing in the DQ will ever
> be
> > selected as there
> > is no overlap.  One or more of your CQ processes
> > must be CPU intensive
> > to dominate the CPU like that; generally there are
> > "some" cycles
> > available to the lower queues.
> >
> > What determines the numbers within the queues?
> > Processes start at the
> > base priority.  If they exceed their quantum
> before
> > otherwise giving
> > up the CPU, their priority number is incremented.
> > This process
> > continues until it reaches the "limit" value.
> > Certain events can return
> > the priority to the base value - such as
> completion
> > of a terminal read.
> > Hoever, if the process is compute bound, it may
> > never rise back in
> > priority.  This is the default behavior of the
> > "DECAY" algorithm.
> >
> > An alternative to DECAY is OSCILLATE, which as the
> > name implies, will
> > pop you back up to the base after you reach the
> > limit.
> >
> > Now, armed with this background, how do you solve
> > your problem?  There
> > are probably a dozen or more different opinions
> > depending on who you
> > ask, but in general:
> >
> > * if the DQ is getting nothing, you must make it
> at
> > least overlap the
> >   CQ by raising the DQ base above the CQ limit,
> >
> > * if the DQ processes then get pushed below the CQ
> > base and hang after
> >   they get started, you may need to raise the DQ
>
=== message truncated ===

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com