jay@silence.princeton.nj.us (Jay Plett) (05/08/90)
The 4.1 Release Notes say: |NFS clients now dynamically determine timeout values, by estimating the |average and deviation of measured response times. This results in fewer |retransmissions when mounting from a slow or overloaded server. When |routing across networks, the transfer sizes are also adjusted |automatically, to handle congestion better on wide-area networks. What I have observed is that NFS write performance to a server outside my subnet deteriorates over time. This is with a 4/60 client and a 4/280 server which tends to be moderately busy. The client is on a subnet of the campus backbone; the server is on the backbone. The client is running 4.1, the server 4.0.3. The remote filesystem is mounted with explicit rsize=8192,wsize=8192 options. Watching with tcpdump while writing a 300k file to the server, I see 8k writes immediately after the file system was mounted. Sometime during the first or second time writing the file, the write size will drop to 4k. Often, but not always, this happens immediately after a block is retransmitted (sometimes it happens when no block is retransmitted). Over some period of time, the write size will drop to 2k, 1k, and finally 512 bytes. This entire process can be accelerated by momentarily disconnecting the workstation's drop cable during the first write after mounting the remote filesystem; the write size immediately drops from 8k to .5k. The same behavior obtains whether the client is running one or four biod's. Meanwhile, NFS performance deteriorates markedly. It takes about 3 seconds to write the 300k file when the writes are 8k, and more than 30 seconds when they are .5k. The alarming part is that the write size seems never to increase! Leaving the remote filesystem dormant for a few hours doesn't help, nor does keeping it busy. It's tempting to conclude that a bad moment on the net will cause permanently abysmal performance. Anybody else have any observations to share? Are there any tunables that I should be fiddling with? Jay Plett jay@princeton.edu