[comp.os.vms] Governing CPU use on small VAXen

GREGG@nemo.math.okstate.EDU.UUCP (04/23/87)

    One of the things about VMS that frustrates me the most is the strict
priority scheduling of CPU use.  All processes at any priority level share
all of the CPU available to processes executing at that priority.  There is
no facility to lower the scheduling priority of a process based on its
CPU use.  I/O boosts do not help much either because as soon as a process
completes a time quantum without giving up the CPU for I/O or some other
asyncronous event completion, it will loose its boost.  The result is that
commands like DIR, that are I/O bound and CPU bound, spend most of their
time executing as CPU bound processes without I/O priority boosts.

    I manage a 750 that averages between 5 and 10 users during the day
(8am-5pm). This machine has 6 megs of memory, and one RA81. The machine is used
by 2 departments, statistics and mathematics.  The math department is more
theory oriented than application, and so they do not spend a lot of time doing
computational things.  The statistics people on the other hand, have several
graduate students running CPU bound simulations for their masters work.  The
other use of the machine is for TeX.  Most of the math professors use LaTeX to
do their exams up nice and pretty.  Also, there are math folks who use
different parts of MATHLIB (An excellent applied math learning tool that does
graphs and solves DEQ's etc..., written by Kevin Carosso, Dan Newman, and Ned
Freed at Harvey Mudd College, a Claremont college {Your welcome guys} :-)). 

    All of these things contribute to a fairly CPU bound job mix when things
get busy.  With strict priority scheduling, it used to take just 2 or 3 TeX'ers
to send response time right through the ceiling.  The statistics folks also
used to occasionally start up one of their simulations at interactive priority
after it had accumulated more than a day of CPU in the batch queue (these folks
were under the impression that it would run in a shorter time period at
interactive priority). 

    All this boils down to a lot of complaints from users about response time
during the day.  The statistics folks now use the batch queues, but the TeX'ers
and MATHLIB folks still create problems for those desiring to just log on and
read mail or do some editing.  As a solution to controlling the CPU bound
processes, I wrote a fortran program that I now run as a detached process to
monitor CPU usage.  Processes using the CPU will have their base priority
lowered so that others who are doing commands like DIR, EDIT, DELETE, etc
(which generally use small amounts of CPU), will not notice the CPU bound
processes. 

    Certain criterion are used to determine when a process is CPU bound, and
when it isn't (so that it's base priority can be raised).  This process also
watches load averages, and will pause selected batch queues when the load
average reaches a certain level (as discussed eariler in this group, large
working set jobs at low priorities can cause thrashing at higher priorities, so
these types of batch queues can be paused during heavy loads to prevent the
jobs in them from displacing a large number of pages from the free list).

    Using information available with $GETJPI, certain processes are ignored and
not considered.  In particular, all processes in the SYSTEM groups are ignored,
as are processes running with BYPASS priv, as are non-interactive processes.
Currently, I use a 7 second interval to examine the jobs.  With this interval,
the process uses less than 1% of the CPU, which I feel is acceptable. 

    I am interested in hearing comments about other solutions that other sites
have to controlling CPU use on small VAXen.  I have heard from other sources
that the 8xxx machines do not degrade at the same rate as the 7xx machines (by
comparison of relative speed and performance).  Have others, who have experience
with switching from a 7xx machine to an 8xxx machine, had the same experience?

Please send comments to me and I will summarize to the group if the responses
warrant it.

Gregg Wonderly
Department of Mathematics
Oklahoma State University