From owner-freebsd-net  Sat May 13 13: 7:48 2000
Delivered-To: freebsd-net@freebsd.org
Received: from silby.com (adam042-051.resnet.wisc.edu [146.151.42.51])
	by hub.freebsd.org (Postfix) with SMTP id 3305437B9AC
	for <net@FreeBSD.ORG>; Sat, 13 May 2000 13:07:40 -0700 (PDT)
	(envelope-from silby@silby.com)
Received: (qmail 11672 invoked by uid 1000); 13 May 2000 20:07:35 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 13 May 2000 20:07:35 -0000
Date: Sat, 13 May 2000 15:07:35 -0500 (CDT)
From: Mike Silbersack <silby@silby.com>
To: Bosko Milekic <bmilekic@dsuper.net>
Cc: net@FreeBSD.ORG
Subject: Re: MFC of mbuf wait and other patch
In-Reply-To: <Pine.BSF.4.21.0005130118180.14833-100000@jehovah.technokratis.com>
Message-ID: <Pine.BSF.4.21.0005131457010.11632-100000@achilles.silby.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


On Sat, 13 May 2000, Bosko Milekic wrote:

>   	As for the "leak," as previously mentionned, it would be helpful to
>   know the state of some processes. In particular, you want to look for
>   process(es) with WCHAN "mballc" or "mclalc" (particularily the ones that
>   seem to be "hanging" on you during the exhaustion). As we've discussed,
>   such processes are typically stuck in the kernel, trying to substitute
>   clusters with mbufs, while continuously timing out on the tsleep()s in
>   the mcluster allocation routine. Unfortunately, such system calls don't
>   return until they decide that they have exhausted all mbufs, too... which
>   means they'll be at it for a while because you usually run out of
>   clusters sooner that you do of mbufs.

Ok, I created the situation again, this time using fstat/lsof to see if I
could get any more additional information.  Unfortunately, I've come up
dry.

What's occuring is that when I hit very close to all mbuf clusters and
mbufs full, apache answers the request, but is unable to stuff the full
~15 of data (loopback's MTU size) into the send queue.  It seems to wait
in mclalc for a few seconds, and goes back to the accept state.  At this
point, the socket in question is no longer attached to any process, and
sits in the LAST_ACK state.  However, unlike the pre-exhaustion sockets,
which are also in LAST_ACK, it seemingly never times out.

I've been attempting to add to netstat so that it tells me more of the
socket internals so that I can hopefully see what's different about these
sockets than others, but it looks like adding all the various fields could
take some time; is there a tool which already shows this info
somewhere?  Unfortunately, I'll be very busy during the next week, so I
won't get time to look much more into it.

> 	The patch looks fine, except for some mbuf.h-related stuff which
>   would probably benefit from a quick review by Brian (green@freebsd.org),
>   as he's done (much needed) cleanups there not too long ago.

I agree.  The mbuf.h changes look safe to me, but there may be something
subtle I missed.

Mike "Silby" Silbersack



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message