Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!dsacg1!dsacg3!ntm1569
From: ntm1569@dsacg3.UUCP (Jeff Roth)
Newsgroups: comp.protocols.nfs
Subject: mountd Performance under Stress
Keywords: mountd nfs performance
Message-ID: <1577@dsacg3.UUCP>
Date: 23 Aug 89 21:56:57 GMT
Organization: Defense Logistics Agency Systems Automation Center, Columbus
Lines: 40


The mount server appears to be becoming a bottleneck for an application in
which we've a large number of PC clients accessing data on a minicomputer
server. On occasion we can have quite a few users issuing multiple mount
requests simultaneously. When this happens we see some of the requests time
out, while users accessing already mounted files continue to receive good
service.

To be precise, the server is a Gould PowerNode 9050 (uniprocessor) with
a full complement of disk and ethernet controllers (four of each), and 
little running on it other than the various network services (next to
no interactive users). PCs start up by mounting and unmounting a file
system to download the application binaries, then mount data(base) files.
With around forty clients accessing the server additional clients' mount
attempts begin to fail (though retries may succeed). (At this point we 
might have a dozen or so new clients trying to mount).

The mount server has to read /etc/exports, and to do the host name to IP
address translation would also have to access /etc/hosts (or the name
server), and it writes /etc/rmtab. So we thought mountd might be having
trouble getting to /etc. But ps "snapshots" showed mountd rarely waiting
on disk.

The mount server obviously also needs CPU cycles, and must compete for them,
mostly with the many NFS server daemons we run. At peaks we see mid-20s
load averages, and with mountd reniced to increase its scheduling priority
we are able to get seventy clients "on" before we again begin to see the
mount requests time out.

Our conclusion's been that we have a CPU bottleneck, with mountd getting
the worst of it. We're a little surprised, though, by the extreme insensi-
tivity of the already-mounted clients to the bottleneck (remember they
continue to see good response time even at peak loads).

I'd be interested in hearing if anyone else has run into this particular
wall in building an NFS application, and what if anything you've done
about it. Or if anyone has any other thoughts on what might be happening.

jroth@dsac.dla.mil  U.S. Defense Logistics Agency  (614) 238-9421
--