Subject: SGI deprioritization

From: <[email-masked]>
Date: Mon, 07 Feb 1994 10:20:16 -0500 (EST)

I recently sent out the following message over the net.  Several
persons who replied requested that I post a summary of the responses.  An
unedited listing of the reponses follows.  The message was

> 	I recall that there was a message over the net about something
> better than "nice" (which hardly works at all).  Can anyone tell me
> how to keep background jobs from slowing foreground jobs to a
> crawl?  Thanks.
> -Don Williams

-------------

Date: Thu, 03 Feb 1994 17:59:28 -0500
From: [email-masked] (Peter Shenkin)
Subject: RE:  CCL:Deprioritizing SGI unix runs
To: [email-masked], [email-masked]

> From: <[email-masked]>
> Date: Thu, 03 Feb 1994 14:21:38 -0500 (EST)
> Precedence: bulk
> 
> 	I recall that there was a message over the net about something
> better than "nice" (which hardly works at all).  Can anyone tell me
> how to keep background jobs from slowing foreground jobs to a
> crawl?  Thanks.

"man npri";  example:  (as superuser, unless it's your job):

	npri -h 150 -p <process-id>

will give the existing job <process-id> a non-degrading priority of 150.  
High priorities (like high "nice" values) slow the process down.  150 is
a good value for background jobs which should never preempt interactive 
work to a significant extent.  In other words, a job with this priority,
if it's the only user process on the system, will use 99+% of the CPU
(e.g., at night), but it will use essentially 0% if someone is at the
console interacting with, say, a molecular graphics program.

The difference between npri and nice is that npri gives a *non-
degrading* priority.  "nice" affects the aging of priorities.

You can also say, "npri -h 150 <jobname> <job_args>" to start up a job 
with a non-degrading priority of 150.

Hope this helps....

	-P.

*****************************************************************************
********************** "So much for global warming...." *********************
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY  10027;     [email-masked];     (212) 854-5143

--------------

Date: Fri, 04 Feb 1994 08:24:50 +0100 (MET)
From: Kris Boulez <[email-masked]>
Subject: RE: CCL:Deprioritizing SGI unix runs
To: [email-masked]
Content-Length: 270

Hello

Look for the manual page on 'npri'. Giving the command 'npri -n 39 -p 
pid' gives the proces with proces id pid the lowest priority and it isn't 
hardly noticed any more that it runs.

Best regards,

Kris Boulez
Biomolecular NMR unit
University of Gent
Belgium

-----------------

Date: Thu, 03 Feb 1994 13:55:56 -0800 (PST)
From: Didier Vanderveken <[email-masked]>
Subject: RE: CCL:Deprioritizing SGI unix runs
To: [email-masked]

Take a look at "npri"... It's really better than "nice".

I'm using a priority around 150 for background jobs.

Didier

---------------

Date: Fri, 04 Feb 1994 08:01:42 +0000 (GMT)
From: Mike Tennant <[email-masked]>
Subject: RE: CCL:Deprioritizing SGI unix runs
To: [email-masked]

On Thu, 3 Feb 1994 [email-masked] wrote:

> 	I recall that there was a message over the net about something
> better than "nice" (which hardly works at all).  Can anyone tell me
> how to keep background jobs from slowing foreground jobs to a
> crawl?  Thanks.

Hi Don,
	there's only really a couple of ways to affect a running job. 
Using the npri command you can decrease the amount of CPU time and the 
nice value (which, as you said, isn't very good) a process has. You can 
also do a kill -20 pid to suspend a job (kill -28 pid restarts it). 
Unfortunately, neither of these will free the memory a process is using, 
so if it's using a lot of memory, SGI has no solution!

		cheers,

			Mike.

 _____________________________________________________________________________
|          _____   ____           ||  SmithKline Beecham Pharmaceuticals Ltd  |
|         /  ___\\\\ _ \          ||  Coldharbour Rd                          |
|         | |___  \\|_| |         ||  Harlow                                  |
|         \____ \ |  _ <          ||  Essex                                   |
|          ___| | | |_| |         ||  CM19 5AD                                |
|         \_____/ |____/          ||  England                                 |
|                                 ||  Harlow (0279) 622000x3328               |
|_________________________________||__________________________________________|
|                                                                             |
|        Mike Tennant                                                         |
|        Email: [email-masked]                        |
|*****************************************************************************|
| 	'Do you have 2 fives for a ten?'  M. Jackson to W. Allen.             |
-------------------------------------------------------------------------------

-----------------

Date: Fri, 04 Feb 1994 11:26:46 -0500
From: Andreas Windemuth <[email-masked]>
Subject: RE: CCL:Deprioritizing SGI unix runs
To: [email-masked]
Cc: [email-masked]

Don,

There are only three ways to do what you want:

    1) Suspend background jobs completely while you are at the console
	("kill -STOP" or "kill -17", resume jobs with "kill -CONT" or "kill -19")
    2) run jobs that use less memory
    3) get more memory for your machine

background/foreground interference is almost always due to 

memory contention, not cpu contention. "nice" only works for
cpu-time. I don't think there is a way to restrict a jobs access
to virtual memory, other than suspending it.

Andreas Windemuth

+--------------------------------------------------------------------
|Columbia University, Department of Biochemistry and Biophysics
|630 West 168th St. BB-221 | tel: (212)-305-6884, fax: 6926, NeXTmail
|New York, NY 10032        | email: [email-masked]
+--------------------------------------------------------------------

----------------

Date: Thu, 03 Feb 1994 12:37:35 -0800
From: "Terry R. Coley" <[email-masked]>
Subject: RE:  CCL:Deprioritizing SGI unix runs
To: [email-masked]
Cc: [email-masked], [email-masked]

Don,

  I suggest you try "Nanny" which can be obtained from
ftp.wag.caltech.edu:/pub/nanny.  I am biased because I am one
of the creators of the program, but it works very well in our
computational chemistry test site at Caltech.  Nanny uses SGI
non-degrading priorities to guarantee good interactive 
response while letting batch jobs only fill background 
cycles.

  Send me mail if you need assistance trying it out.

	Regards,

        - Terry

Terry R. Coley
[email-masked]
Parallelograms
PO Box AA
Pasadena, CA  91102
818-577-5515 Voice/Fax