Date: Wed, 6 Mar 2002 15:21:14 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: "Jan L. Peterson" <jlp@softhome.net>, freebsd-stable@FreeBSD.ORG Subject: Re: crashes on 4.5-RELEASE Message-ID: <200203062321.g26NLE959185@apollo.backplane.com> References: <200203062302.aa66019@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
:...
:> in a heavily loaded environment would be enough to cause the output
:> buffer to grow to a considerable size.
:
:Yes, that's certainly possible. Can someone who has a crash dump
:handy run
:
: netstat -m -N kernel.X -M vmcore.X
:
:to get the mbuf stats? I think with TCP the buildup would be much
:slower, as a (as far as I remember) retransmits are limited. In
:-CURRENT (which is the only place I have seen the IPFW/NFS mbuf
:exhaustion) I think sosend() was returning EPERM, but the mbufs
:were still building up. That may be a new bug somewhere.
:
:Ian
If I remember right there are no retransmits with a TCP mount, but
if you have a lot of client processes banging out NFS requests and
one direction of the TCP link stalls you can get a build up. This
would be further irritated by nfsiod doing look-aheads.
I do not know if the build-up itself is even responsible... it could
very well be the *rate* of the build-up... i.e. a sudden burst of
a hundred kilobytes all at once might not exhaust the mbuf
pool, but it could certainly exhaust our free page reserve and prevent
an interrupt from being able to allocate an mbuf temporarily.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200203062321.g26NLE959185>