Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!ames!elroy!david From: david@elroy.Jpl.Nasa.Gov (David Robinson) Newsgroups: comp.os.vms Subject: Re: Performance and batch jobs. Message-ID: <5083@elroy.Jpl.Nasa.Gov> Date: 18 Dec 87 12:13:34 GMT References: Organization: Image Analysis Systems Grp, JPL Lines: 50 In article , WIZARD@RITA.ACS.WASHINGTON.EDU (The Bandit "." "." "." "", on" "RITA) writes: > Michael J. Porter writes: > > > We have all our users submit heavy crunch jobs as batch. The batch > > queues have a lower priority than interactive, so our interactive > > users are not affected. Putting CPU time limits on users will > > insure that they submit jobs. We simply threatened to do this and > > our users cooperated making life easier for all. > > This works in most instances, but you have to realize that base priority > is not the only factor involved. The base priority (currently) only > determines when the job will get the CPU. An example will illustrate > the problem. > > We had a user here who submitted three batch jobs, and the system died. > Setting the base priority to 0 did not help. Suspending the processes did. > All three batch jobs were running a BASIC program the user had written, > and all three were executed through the BASIC interpreter, rather than > being compiled and linked. The program's job was to resequence another > BASIC program. The problem was that the virtual working set for these jobs > was huge, and the jobs were causing page faults like crazy. BASIC was > installed, and page sharing wasn't the problem. The jobs just didn't want > the same pages at the same time. The one thing I have always hated about the VMS priority scheme was the lack of granulatity. There are 32 levels and one almost never runs anything over 16. So now you are down to 16 levels. With the priority boosting that is given to I/O you have considerable overlap. An example is to have a priority 3 job doing raw character at a time I/O. Since I/O gets a big boost the priority 4 jobs get next to no work done. People have mentioned it before but having a batch queue with priority 3 and interactive users at 4 works fine if you have CPU intensive jobs but if you have I/O intensive batch jobs they will serverly hurt interactive priority. A better scheme in VMS is to have the base batch priority 2 or more levels below interactive so that I/O bound jobs don't get excessive CPU. I also advocate running Interactive users at 5 or 6 to allow for a bigger range for the batch queues. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!