Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!krowitz@EDDIE.MIT.EDU@mit-kermit.UUCP
From: krowitz@EDDIE.MIT.EDU@mit-kermit.UUCP (David Krowitz)
Newsgroups: mod.computers.apollo
Subject: slow DN560 when being backed up -- the solution!
Message-ID: <8701212052.AA14324@EDDIE.MIT.EDU>
Date: Wed, 21-Jan-87 15:37:04 EST
Article-I.D.: EDDIE.8701212052.AA14324
Posted: Wed Jan 21 15:37:04 1987
Date-Received: Thu, 22-Jan-87 02:02:53 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20
Approved: apollo@yale-comix.arpa

Thanks to RPS at Apollo I have the solution to the problem
of tape backups via the network and general network disk I/O
causing a node to get really slow. Using NETSVC -S 2 -P 512 to
limit the amount of real memory which the page request servers
can use for remote paging requests to 1/2 Mb on a 2Mb DN560
seems to give the page request servers enough memory to operate
efficiently while leaving some memory for the local user of the
node. By default, NETSVC normally lets the page request servers
use all of the memory on the node, and when their is a lot of
network disk I/O going on (as when you are doing a backup of the
disk from a tape drive on another node or when a diskless parter
is doing a lot of paging or even when someone is simply accessing
a lot of data) the page request servers wind up eating up *all* of
the node's memory forcing the local user's processes and the
display manager into paging. I have changed all of the 
`node_data/startup.?* files on our network to use the -P 512
option, and even the 4MB DN460/660's now seem to be faster when
there is heavy network disk I/O going on.

-- David Krowitz