David Randall ([log in to unmask]) wrote:
: Clues sought to the black arts of 3000 performance tuning. =
:                     ------QUANTUM-------
: QUEUE  BASE  LIMIT  MIN    MAX    ACTUAL  BOOST  TIMESLICE
: -----  ----  -----  ---    ---    ------  -----  ---------
:  CQ    152    200   1      2000   18      DECAY    200
:  DQ    202    238   2000   2000   2000    DECAY    200
:  EQ    160    238   1      200    25      DECAY    200

: I have tried oscillating the DQ and EQ but it seemed to make
: things worse (fast performance for a period then nothing =
: for several seconds)
You might try setting the minimum quantum for the cq to a larger
number.  25 to 75 might insure that when a process gets the cpu
it is able to do a bit more work.  Also, reduce the maximum Quantum
from 2000 to maybe 400. This should avoid CPU intensive processes from
driving the actual quantum up high and then the interactive users
having to drive it back down.

You might try changing the dq to 400, 400 (min,max) or even 200,200
if you have a lot of batch jobs at once.

But remember, there is only so much that can be done in a given timeslice,
if you give more cpu to STORE then someone (online user or batch job) must
loose.

Watch out for memory thrashing, and disc bottlenecks.  Lengthing the
queues and overlapping them as other responses have suggested is also
a good way to "punish" heavy cpu users and "rewarding" short jobs.
--
 James Overman HP Support Technology Lab  Roseville, CA