Date: Sun, 22 Aug 2010 17:40:30 +0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: freebsd-net@freebsd.org Subject: Re: 8.0-RELEASE-p3: 4k jumbo mbuf cluster exhaustion Message-ID: <AANLkTikYMU=wML_z=HDnkUF1PGYMVa1q-QWTrkxD%2B7EP@mail.gmail.com> In-Reply-To: <AANLkTikrbCFHz-CnuYcgH2JzpeH5hob0Aa2y5dwn3Hvv@mail.gmail.com> References: <AANLkTikrbCFHz-CnuYcgH2JzpeH5hob0Aa2y5dwn3Hvv@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I disabled tso, tx chksum and rx chksum. This fixed the 4k jumbo allocation growth. Turning on tso on a live proxy didn't affect jumbo allocations. Turning on txcsum caused jumbo allocations to begin growing again. DIsabling txcsum again caused jumbo allocations to stop increasing, but it doesn't seem to be decreasing back to the steady state (~ 8k.) Turning on rxcsum didn't affect jumbo allocations. So it seems txcsum is the culprit here. Adrian On 22 August 2010 16:11, Adrian Chadd <adrian.chadd@gmail.com> wrote: > Hi, > > I've got a Squid/Lusca server on 8.0-RELEASE-p3 which is exhibiting > some very strange behaviour. > > After a few minutes uptime, the 4k mbuf cluster zone fills up and > Squid/Lusca spends almost all of it's time sleeping in "keglimit". > > I've bumped kern.ipc.nmbclusters to 262144 and kern.ipc.jumbop to > 32768 but the system will slowly crawl towards filling that zone. > > The box has a bce on-board NIC and is using ipfw to handle redirecting > traffic to/from the box for transparent TCP interception. It's > handling around ~30,000 concurrent connections at the moment. > > I have other very busy proxies on FreeBSD-7.x pushing a few hundred > megabits without any issues. This box falls over after ~ 20 mbit. > > If I bypass redirection and/or kill squid, the 4k cluster count drops > back down to < 500 and stays there. > > Does anyone have any ideas on where to begin debugging this? > > Thanks, > > > Adrian >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikYMU=wML_z=HDnkUF1PGYMVa1q-QWTrkxD%2B7EP>