Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!raven.alaska.edu!casbah.acns.nwu.edu!eecs.nwu.edu!phil
From: phil@eecs.nwu.edu (William LeFebvre)
Newsgroups: comp.unix.internals
Subject: Re: "Nice" or not to "nice" large jobs
Keywords: scheduling priority nice
Message-ID: <1991May16.145927.9815@casbah.acns.nwu.edu>
Date: 16 May 91 14:59:27 GMT
References: <3197@sparko.gwu.edu>
Sender: news@casbah.acns.nwu.edu (Mr. News)
Reply-To: phil@eecs.nwu.edu (William LeFebvre)
Organization: Northwestern University
Lines: 34
Nntp-Posting-Host: pex.eecs.nwu.edu

In article <3197@sparko.gwu.edu>, sheryl@seas.gwu.edu (Sheryl Coppenger) writes:

|> I have a user challenging that policy on the grounds that UNIX
|> will take care of it automatically.

Tell the user s/he is wrong.

The VAX BSD system (4.1 and 4.2, not sure about 4.3) would automatically
renice any process that exceeded 10 CPU minutes to a nice of 10.  Note
that the default for the "nice" command is 4, so it was in a user's best
interests to use the "nice" command explicitly.

SunOS does NOT do this.  There are times when I wish it did.

Furthermore, if there is a CPU intensive or paging intensive or
(I think even) an i/o intensive process running, interactive performance
is *noticeably* degraded.  Get about 2 or 3 of them running and you
have a system that crawls for the interactive users.  But, renice all
three of those hog processes to even 4 and interactive use is once 
again snappy.

So even on the VAX you had to put up with about 20 minutes of "hell"
before the system would renice the offending process.

Your policy is a good one.  Stay with it.  Users who are going to 
run long-term jobs should take the responsibility on themselves to
insure that the process does not interfere with smooth interactive
activity.

		William LeFebvre
		Computing Facilities Manager and Analyst
		Department of Electrical Engineering and Computer Science
		Northwestern University
		<phil@eecs.nwu.edu>