Date: Fri, 10 Jan 2003 17:14:46 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Jeff Behl <jeff@expertcity.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: when are mbuf clusters released? Message-ID: <20030105204407.P20123-100000@patrocles.silby.com> In-Reply-To: <3E14A22B.5070203@expertcity.com> References: <3E108C31.9060403@expertcity.com> <20021230132145.N22880-100000@patrocles.silby.com> <3E14A22B.5070203@expertcity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Urk, this message got stuck in my drafts folder, sorry for the delay. On Thu, 2 Jan 2003, Jeff Behl wrote: > Thanks for the info. Could you explain how mbuf clusters and mbufs are > related? i'd like to better understand how we can run out of one and > not the other. also, is there an upper value for mbuf clusters that we > should be wary of? again, the tuning page is quite vague on this. > 64000 seems to not do the trick so i was thinking of 2X this. we have > plenty of memory (1GB and the machine only runs apache). I think someone else answered this, so I'll skip doing so. As to what a good upper value is... well, 2K per cluster, how much memory you wish to dedicate to clusters is up to you. There *shouldn't* be any limit on the number besides memory usage, but remember that kernel address space is used for many other things, so don't waste it. :) > for those interested, we think we've found why we're getting lots of > connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad > interaction between IE and flash (we think). these machines serve popup > adds (sorry!), and we're guessing that when a user with a slower > connection gets one of these pop-ups and kills the window before the > flash file is done downloading, IE leaves the socket open...sorta, and > here's where it gets interesting. it leaves it open, but closes the > window (sets it to 0)...or is the plugin doing this? apache is done > sending data and considers the conenction closed, so its client timeout > feature never comes into play. but there is still data in the sendq, > including the FIN, we believe. BSD obeys the spec (unfortunately) and > keeps probing to see if the window has opened so it can transmit the > last of the data. this goes on indefinitely! so we get gobs > connections stuck in fin_wait_1. interestingly, we have a solaris > machine serving the same purpose and it does not have the problem. it > seems to not folluw the rfc and silently closes the conenction after a > number of tries when a socket is in fin_wait_1. these seems more > reasonable to me. this seems (as i've read from other posts as well) > quite an opportunity for a DoS attack....just keep advertising a window > of 0. a single client could easily tie everything up in fin_wait_1... Can you recreate the problem with windows machines sitting around your office? If so, try capturing tcpdumps of the situation occuring on FreeBSD, and also it not occuring on Solaris so that we have something to look at. > > anyone think of a workaround (besides not serving pop-ups :) Well, not serving popups might be the simplest option, but I suppose that any fix to the problem would benefit non-popup servers too, so it's worth looking into. > jeff 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?20030105204407.P20123-100000>