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 Message-ID: <Pine.BSF.4.21.0005131457010.11632-100000@achilles.silby.com> In-Reply-To: <Pine.BSF.4.21.0005130118180.14833-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005131457010.11632-100000>