Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NFS client renders system unusable



Michael van Elst wrote:
pitney.brad%googlemail.com@localhost ("Brad Pitney") writes:

On Sat, Mar 15, 2008 at 5:39 AM, Sarton O'Brien 
<bsd-xen%roguewrt.org@localhost> wrote:
 >> yp_order: clnt_call: RPC: Unable to send; errno = No buffer space
 >> available
 large amount of connections ... all those p2p connections would equate
 to nfs client conections.

I doubt that each client connection corresponds to one NFS connection.
There should be only one connection per NFS _mount_.


Ok, I guess I was trying to imply that there would at least be a high level of access but low amount of data actually being transfered. I have no idea how nfs truly works.

Strange, when my NFS server goes away (maybe I've updated it and
rebooted), my NFS clients just stall and wait for the server to come
back, once it does, just resume as if nothing happened with exception
of a few messages like this:
Mar 13 00:13:44 nfs-client /netbsd: nfs server
nfs-server:/media/data/netbsd/current/obj: not responding

I would guess that when the NFS connection stalls his application
just piles up connections. The number of open but waiting connection
grows beyond bounds and this is eating the (network) buffer space so
that finally even the single NFS connection fails due to lack
of memory.

The answer is to limit the number of open connections in his
application or if there is already a limit, to provide the
buffer resources necessary. With NetBSD this is the
kern.mbuf.nmbclusters value and maybe vm.nkmempages too.



Yeah was inclined to think there would be a sysctl for something like this, I'll definitely have a look.

The client was doing this even when the server was available but hopefully I can tweak the required resource to handle the required connections. Thanks for the pointer.

Sarton


Home | Main Index | Thread Index | Old Index