Date: Fri, 11 Oct 2002 01:44:28 -0700 From: Sean Chittenden <sean@chittenden.org> To: "Hartmann, O." <ohartman@klima.physik.uni-mainz.de> Cc: stable@FreeBSD.org Subject: Re: NFS server not respnding! Message-ID: <20021011084428.GB57337@perrin.int.nxad.com> In-Reply-To: <20021010111438.O49715-100000@klima.physik.uni-mainz.de> References: <20021010111438.O49715-100000@klima.physik.uni-mainz.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Using FreeBSD 4.6.2-pl2 and FreeBSD 4.7-RC2 on our server system > (one 4.7-RC experimental system) and utilizing AMD for mounting home > space and other services via TCP protocol results in > > nfs server 134.93.180.216:/usr/homes: not responding > nfs server 134.93.180.216:/usr/homes: is alive again > > very often, when load of the appropriate client is very high. That > happens when on our number crunching systems utilization of CPU time > is high or many users try copy from and to via SAMBA to the main NFS > server system. There's one setup that I maintain where I see this a lot. If I mount the ports dir with rw perms over NFS, _AND_ am using CVSup to update the ports, I can reliably crash the NFS server. I'm not sure if this is because I'm taxing the IDE drives too much or because there's some glitch in NFS someplace. Tuning and TCP vs UDP hasn't made a difference. I'm going to give netdump_client a shot here sometime soon and see if I can't get some kind of debugging info out of the kernel. As it stands, the system has 2GB of RAM and I only allocated 1GB to swap (which isn't ever more than 1% used). FWIW, why isn't netdump_client a part of the standard distro? Seems like an invaluable tool in debugging. -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021011084428.GB57337>