Robert Schulze wrote:> Hi,
>
> we are running an NFS server (8.2-STABLE/amd64 from 2011-09-08) with
> several 8.1-RELEASE-p1/amd64 clients (webservers). After updating the
> server, we now realize a slight increase in udp datagrams "dropped due
> to full socket buffers", which wasn't the case in the previously
> installed 8.2-STABLE from 2011-05-08. This also results in higher
> averages in HTTP request time on the clients.
>
Well, there isn't much that changed in the krpc or NFS server's handling
of UDP during that period. The only change in the krpc is r225384 and I
can't think how that would have this affect. (All it does is avoid a loop
in the kernel when msleep() returns EINTR or ERESTART.)
> Nothing was changed on the configuration regarding sysctls or loader
> tuneables.
>
> kern.ipc.maxsockbuf is at 1024000 on the server.
>
> Was there a change which could cause the drops? Should this tuneable
> be
> increased further?
>
You can certainly try this. (It defaults to 2*1024*1024 in -current now.)
> Regarding maxsockbuf: is this number per-socket? So does one have to
> keep in mind that there could be maxsockbuf*maxsockets allocated for
> UDP?
>
It's per-socket, but in the case of the NFS server, it only uses one UDP
socket for all requests. (I have no idea what else you are running that
uses UDP?)
> I'm willing to provide further information upon question.
>
Sounds to me like you've bumped into some second-order effect. One thing
I'd
try (you didn't mention where you currently have it set) is bump the # of
nfsd
threads up. For example, you can set it to 64 by putting this line in your
/etc/rc.conf.
nfs_server_flags="-u -t -n 64"
If you have too many of them, the extra ones just sit waiting for a request and
don't take up many resources. On the other hand, if you don't have
enough of
them, requests will get backed up in the socket's receive queue.
I'll also mention considering using TCP mounts from the clients.
(I can't remember if we've already had this discussion:-)
Good luck with it, rick
> with kind regards,
> Robert Schulze
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe@freebsd.org"