NFS problem on 4/280

[rgb at lamont.ldgo.columbia.edu]

We have a 4/280 running under 4.0.3 which is providing abysmal NFS
performance and are at wit's end to figure out what gives.  The same
problems existed under 4.0.1 and have persisted through a complete
reinstallation of the newer OS.

This machine is used primarily as an NFS file server providing access to
fairly large (~ 30 Mb) image files. We have 32 Mb of memory (128 Mb of
swap) and two 900Mb NEC 2363 drives controlled by a Xylogics 7053.  Our
problems seem to be coming from one of these disks which is configured as
a single partition with about 855 Mb of usable space. The file system on
this disk was built with newfs, using no special options, i.e., we've made
no attempt to fine-tune the file system. The file system is usually
between 90% and 95% full.

NFS access, both read and write, to large files in this file system from a
6250 bpi tape drive on a 3/180 running OS 3.4 is painfully slow.  We are
totally mystified as to why a SPARC machine doing nothing but NFS serving
can't keep up with a slower client that is typically running under a
heavier load of ND- and NFS-serving of its own. The nfsds on the 4/280
scarf up between 80% and 100% of the server's CPU, leaving the machine all
but useless to any other process. Since there are 8 nfsd processes
running, which typically divide the CPU evenly between them, is it
possible that they are in contention with each other? Reducing the number
of daemons to 4 makes no difference.

Access to large files in smaller filesystems on the 4/280 does not seem to
exhibit this problem, nor do local accesses of files in any filesystem.
The problem seems to be confined to NFS accessing the large partition.
traffic, nfsstat, and every other diagnostic we've tried to run has not
shown anything unusual going on -- lots of reads and writes, but no
collisions or any other nastiness.

Does anyone have any experience with this kind of problem? We've got
reasons for needing this large file system and would prefer not to hack it
into smaller chunks.

				Bob Bookbinder