Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpl-opus!jewett
From: jewett@hpl-opus.HP.COM (Bob Jewett)
Newsgroups: comp.sys.hp
Subject: Re: Backup over net (Was Re: NFS Super users?)
Message-ID: <63300008@hpl-opus.HP.COM>
Date: 1 Aug 89 22:01:06 GMT
References: <2924@helios.ee.lbl.gov>
Organization: HP Labs, High Speed Electronics Dept., Palo Alto, CA
Lines: 54

> >I just did try it.  The machine doing the find/cpio was an 835, the
> >filesystem being traversed was NFS-mounted from a 350.  ...
> >On what sort of configuration do you have a response-time problem?
> 
> Oh, on pretty much any NFS client/server combination. It doesn't matter
> who makes the clients and servers, ... 
> ... such machines can still be brought to their
> knees by doing a du of a large (100 MByte+) remote file system.

The filesystem I was traversing was ~300MBytes.

> >We have found that the 835 can do a "du" on /nfs/server350 about twice as
> >fast as the 350 can do a "du" on its own disks.
> 
> This does not make sense.
...
> You must be seeing caching effects here.

Yes, it does not make sense, but it is what we observed.  Again, the
filesystem was large, so any cacheing should not have been effective.
The actual value of "ninode" (the maximum # of in-core inodes) on the
fileserver is 760.  I just tried it again, and got nearly equal clock
times in the two cases, but when the 835 is doing the du of the
NFS-mounted system (300MBytes, 746 directories) it only uses about 16%
of the 835 CPU, plus about 40% of the fileserver's CPU in nfs-demons.
The local du by the fileserver (350) uses about 55% of the CPU.
(In both cases the clock time was about 6 minutes.)

> The times you have seen suggest to me two things: ...

Another possibility is that looking at the data from the disk is a
significant part of the job, in which case it is possible to win by doing the
processing on a fast CPU.

> This is why it is generally better to do local I/O than use some network
> file system.

Agreed.  It's just that the penalty is not always as large as you seem to
have experienced.

> ... so if the NFS servers are
> busy for long periods of time, users will see response times drop
> because the CPU spends most/all its time processing NFS requests.

We have seen unacceptable response time due to NFS in two cases:

1) A hard-mounted system goes down and blocks all the nfsd processes

2) A program dumps a megabyte core in an NFS directory, using up all the
   net bandwidth

Bob Jewett

[ not an official statement of the Hewlett-Packard Company ]