Date: Wed, 23 Apr 2008 14:30:50 +0900 From: gnn@freebsd.org To: Chris Pratt <eagletree@hughes.net> Cc: Robert Watson <rwatson@freebsd.org>, net@freebsd.org Subject: Re: zonelimit issues... Message-ID: <m2hcdt87ed.wl%gnn@neville-neil.com> In-Reply-To: <F2373438-DA8B-4B6D-8E5E-D52520C4AEC7@hughes.net> References: <m2hcdztsx2.wl%gnn@neville-neil.com> <48087C98.8060600@delphij.net> <382258DB-13B8-4108-B8F4-157F247A7E4B@hughes.net> <20080420103258.D67663@fledge.watson.org> <33AC96BF-B9AC-4303-9597-80BC341B7309@hughes.net> <m2prsj4pqx.wl%gnn@neville-neil.com> <F2373438-DA8B-4B6D-8E5E-D52520C4AEC7@hughes.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At Tue, 22 Apr 2008 06:35:38 -0700, Chris Pratt wrote: > > > On Apr 21, 2008, at 12:43 AM, gnn@freebsd.org wrote: > > > ...snip > > > > Well there are plenty of us motivated to get at these issues. Can you > > do me a favor and characterize your traffic a bit? Is it mostly TCP, > > The traffic that seems to take us out is TCP port 80. I'll make a > generalized guess but it does seem to follow. We freeze on one of > two dramatically heavy use days for our industry (Sunday and Monday > evening). The hang will actually occur on Monday or Tuesday > following these days if sufficient traffic hits us. It has not > always followed this pattern but most frequently. There is always a > high presence of high frequency attacks of various sorts. For > example referer spam posts which hit us hard on our busy > evenings. So it is TCP and I would presume we usually have the > establishment of many useless sessions that could cause us to bump > up against limits and cause exhaustion coupled with our real traffic > peaks. > Interesting, but with TCP it should be easier to tune this, in particular because TCP has backoff once a packet drops. I gather you are using facilities, like accept filters, that make it easy to drop less useful traffic? > This thread has given me several things to try and I'm adjusting (e.g., > nmbclusters) upward to see what happens. Sounds good. Using netstat -m and netstat -an are a good way to watch this issue. -m is the number of mbufs/clusters in use and -an will show you all sockets, but what you want to check on s the number of bytes in the recv and send socket buffers, which are the 2nd and 3rd columns. > I should also mention that this system has the natural limitations > on it's traffic ceiling of two T1s on two NICs and a 3rd LAN NIC > fielding continuous round-robin mysql replication and rsync style > mirroring. It uses two bge interfaces and one server type em > interface. It's always troubled me that the zonelimit issues have > always been associated with higher volume circuits (in what I've > read). But since our issue is very directly related to traffic > levels and seem to occur at times where my monitors show us way over > committed on the two outward facing T1s, I'm still going to proceed > with the adjustments and see if it increases our survivability. Since zonelimit is a state reached when your system is out of resources it makes sense that the higher the traffic the sooner you'll reach it. > Thanks for your time on this. > No problem, it's what I like to do :-) Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2hcdt87ed.wl%gnn>