Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!ENGVAX.SCG.HAC.COM!CHRIS
From: CHRIS@ENGVAX.SCG.HAC.COM.UUCP
Newsgroups: mod.computers.vax
Subject: Re: Tuning (Open mouth, receive hot flaming death)
Message-ID: <8703261155.AA14384@ucbvax.Berkeley.EDU>
Date: Wed, 25-Mar-87 13:48:00 EST
Article-I.D.: ucbvax.8703261155.AA14384
Posted: Wed Mar 25 13:48:00 1987
Date-Received: Sat, 28-Mar-87 02:21:57 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 39
Approved: info-vax@sri-kl.arpa

[bug poison]

     Sigh.  I open my mouth and find out just how spoiled I really am.  I did
not mean to get into a general tuning debate when I sent my message to INFO-VAX
describing what I have learned about working set parameters, but I guess that
I wasn't careful enough in describing where I'm coming from.

     Where I'm coming from is an environment where we have at least "enough"
memory, and a management that knows enough to listen to us when we say that we
need more *before* it's too late.  We also have a general mix of users, very
few of whom are running massive jobs (these run a couple of times a month at
best).  I think that our systems run with what might termed by DEC a "typical"
workload environment.  I still say that in this case, where you don't have big
jobs and where you have enough memory, swapping is generally *very* bad.

     There are cases when swapping is good.  These cases *usually* occur on
systems that don't have "enough" memory or that run massive jobs (there may be
others, but they haven't been pointed out to me, yet...).  I have no experience
trying to run memory-poor systems, and I really do feel sorry for those of you
that are stuck with doing so, but if you don't have enough memory, all that I
can suggest is that you start (or keep) bitching to whomever can get you more
and that you do the best you can with what you've got.  I get no commissions,
lunches, 6 packs of Dr. Pepper, or any other compensation for you getting more
memory, but I firmly believe that having "enough" memory is akin to having
"enough" disk-space, it's just harder to measure.

     I feel that massive jobs should be run a) in a batch queue or b) on a
machine dedicated to (and tuned for) running massive jobs.  With a batch queue,
at least you can suspend the jobs in the queue during "peak" hours or set the
queue to a priority lower than interactive so that they get swapped out first
(again, in the general case, I know all about batch jobs doing a lot of I/O
screwing this model up).  With a dedicated "big-job" machine, I'm sure that
there are people running them who would be willing to give pointers to those
who might need it.  I could come up with some guesses that I think are pretty
good that are in reality dead wrong, so I won't say anything.

-- Chris Yoder                  UUCP -- {allegra or ihnp4}!scgvaxd!engvax!chris
   Hughes Aircraft Company  Internet -- @ymir.bitnet:chris@engvax.scg.hac.com
                                ARPA -- chris%engvax.uucp@usc-oberon.usc.edu