"Nice" or not to "nice" large jobs

[System Admin Mike Peterson]

In article <3197 at sparko.gwu.edu> sheryl at seas.gwu.edu (Sheryl Coppenger) writes:
>
>Historically (since before I worked here), there was a policy for
>users running large jobs which ran along these lines:
>	1)  Run them in the background
>	2)  Start them up with "nice" to lower priority
>	3)  Only one such job on a machine
>I have a user challenging that policy on the grounds that UNIX
>will take care of it automatically.

Our policy for nice/renice is:

0  - "short" processes/jobs (compilations, or up to 5 minutes cpu time).
1  - "medium" processes/jobs (up to 1 hour cpu time).
2  - "long" processes/jobs (all other jobs).

The main intention is to get "background" number crunching jobs out of
the way of foreground/interactive users. While it is true that cpu-bound
processes will get less cpu than an I/O bound process at the same
"niceness", we want the separation to be bigger, and to allow short jobs
to hog the cpu relative to medium/long jobs, and allow medium jobs to
hog the cpu relative to long jobs (which may run for days). We use only
niceness 0, 1 and 2 because those are the only ones that are really
different on our central system (Apollo Domain/OS) - we would use a wider
spread of nice values (e.g. 5, 10, 20) if they worked properly. We allow
more than one job of each type to be run, though we would like to get a
batch queueing system to work to control the number/sequencing of some
of the long jobs (some of them step all over each other in terms of disk
I/O so the system is much more productive if only one of them is running
at a time).

Mike.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system at alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775