[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Thu, 9 Jul 2009 08:49:53 +0300
Jukka Marin <jmarin%embedtronics.fi@localhost> wrote:
> I'm using TCP for all NFS mounts now.. we'll see if that helps. It would
> be great if one could get over an NFS problem without the reset button,
Interestingly I've been using TCP for NFS for a long time (years), yet
lately I tend to often see these (it might be since the
netbsd-4->netbsd-5 upgrade, but I'm not sure. Since most of the time
this seemed harmless I didn't look into it much until now):
nfs server foo not responding
nfs server foo is alive again
In all cases, the delay between the two is quite short, in the order of
a second or two at most. Sometimes these are rare and performance
doesn't seem affected much. However, at other times these occur
non-stop, and performance is greatly reduced, a CVS update from a local
repository mirror mounted via NFS can then take at least three to four
times longer than usual.
I suspected a possible problem with NFS threads being too low, but
increasing client-side vfs.nfs.iothreads sysctl, and number of threads
in nfsd_flags on server-side didn't seem to help (despite top showing
more available threads).
So yesterday I decided to switch to UDP to verify if it's better.
However, after a certain number of hours, all processes on the client
locked in tstile wchan/state and I had to reboot the client.
The problem doesn't seem to be network related, as an ssh
connection to the server keeps working when this happens, as well as
HTTP/FTP to the server and outside. I see no network interface
diagnostics in dmesg either. This didn't occur again, but I'll keep
using UDP a bit for now and see how it goes.
Main Index |
Thread Index |