HP3000-L Archives

November 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Brian Duncombe <[log in to unmask]>
Reply To:
Brian Duncombe <[log in to unmask]>
Date:
Tue, 21 Nov 1995 13:13:13 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
At 06:50 AM 11/21/95 -0800, Joe Elliott  [log in to unmask] wrote:
>We here at the college are currently using dataexpress.  One big gotcha
>is that dataexpress will grab as much CPU as possible when it starts.  If
>the CPU is not busy then it will grab up to 70-80 percent and that locks
>up my users right and left.  I have a job that runs about every ten
>minutes to put all dataexpress users into a lower que, but if the user in
>dataexpress takes the cpu long enough then the scheduled job can never
>log on.  This is a hassle, I am forced to keep checking on the CPU to
>ensure that no one person has locked up all the other users.  This has
>been our frustration for some time and if anyone out there has some ideas
>I would love to here them.
 
Joe,
 
DataExpress, like any other reporting tool, appears to the system to have
characteristics very much like a batch job (ie. when it is compiling the
data from a request, it is always ready to run).  Normally, a process in the
CQ that
uses cpu without stopping frequently on a terminal read will settle to the
bottom of the queue and let other processes compete more favorably for the
cpu.  Two reasons why this might not be true are as follows:
 
1) The system is short of main memory and so, even though higher priority
processes would like to run, they cannot do so until their memory
requirments are satisfied (swapped in).  In the interim, the DataExpress
process with a lower priority but with all of it's resources immediately
available will be allowed to run.
 
2) You have specified "oscillate" for the CQ in the TUNE command.  In this
case, the DataExpress process quickly sinks to the bottom of the CQ at which
point it is elevated back up again.  A similar result can be obtained by
making the range of the priorities in the CQ too narrow.  Adjusting the
other TUNE parameters to cause the priority of a busy process to fall faster
can also be effective.
WARNING/ADVICE: when you experiment with the TUNE command, make your changes
one at a time so that you can tell what effect they have.  Also, don't make
radical changes since these can have a detrimental effect on the system.  It
is better to make conservative changes, one at a time and observe the
results than to make a giant change all at once.
 
There are several products available that allow you to control the priority
allocation and or cpu resources for a process or class of processes.  HP has
a product called "Workload Manager" and Unison has a product called "KLA
Express".
 
An old trick that can sometimes be used is to assign these DataExpress users
to the EQ (assuming that queue is not normally used).  You then adjust the
EQ so that it's best priority is lower than that of the CQ and it's worst
priority is either the same as the CQ or slightly worse.
 
It has been my experience that with a bit of experimentation, user processes
such as DataExpress (and tasks such as compiles) can be controlled and the
service levels provided to the general population can be improved to an
acceptable level.
 
Brian Duncombe ([log in to unmask]) - M.B. Foster Software Labs
"Inside every large program is a small one struggling to get out."
          C. A. R. Hoare

ATOM RSS1 RSS2