From owner-freebsd-stable@FreeBSD.ORG Thu Mar 6 21:59:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD6E71065675 for ; Thu, 6 Mar 2008 21:59:47 +0000 (UTC) (envelope-from gemini@geminix.org) Received: from geminix.org (geminix.org [213.73.82.81]) by mx1.freebsd.org (Postfix) with ESMTP id 802E18FC29 for ; Thu, 6 Mar 2008 21:59:47 +0000 (UTC) (envelope-from gemini@geminix.org) Message-ID: <47D063FF.7000409@geminix.org> Date: Thu, 06 Mar 2008 22:37:03 +0100 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080129 SeaMonkey/1.1.8 (Ubuntu-1.1.8+nobinonly-0ubuntu1) MIME-Version: 1.0 To: Scott Oertel References: <47D006F7.1030607@scottevil.com> In-Reply-To: <47D006F7.1030607@scottevil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JXNlv-0005XV-MO; Thu, 06 Mar 2008 22:59:46 +0100 Cc: FreeBSD Mailing List Subject: Re: accf_http and incqlen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 21:59:47 -0000 Scott Oertel wrote: > (I sent this to freebsd-questions, but I didn't receive any replies, > thought I would try my luck here) > > I setup the http accept filter with apache and I was having a hard time > understanding this, maybe you guys could help out. > > I've tested this among various version of freebsd, primarily FreeBSD > 6.3-RELEASE, and with various > apache configs, and it appears to behave the same across the board. > > So why is it that it "appears" that the TCP connections never terminate, > just stay in a state of ESTABLISHED, and why doesn't this queue ever > flush itself, is it normal, if it is, what happens exactly when the > queue fills up to maxqlen. From the netstat output below, you can see > that the incqlen is maxed out. I've done quite a bit of searching > regarding this queue but haven't found any real solid information which > describes what happens when it fills up, and at the same time this is > going on, I have 517 established connections to port 80. > > ]# netstat -an|grep "\.80"|grep ESTAB|wc -l > 519 > [...] Last time I looked (in FreeBSD 4.x) these were connections that got stuck in an early stage, that is, before the HTTP request had been received. The 'accf_http' filter which wants to parse said request waits forever in this situation because there is no timeout implemented, as far as I recall. So these would-be HTTP connections pile up over time. The actual cause are quite likely port scans and such from the Internet. I don't know whether one would eventually run out of resources, but so many stuck connections certainly look sick, and you can't see the wood for the trees if you need to debug something under these circumstances. What I did instead was compile Apache 1.3 with the flag -DACCEPT_FILTER_NAME=\\\\\"dataready\\\\\" added to CFLAGS in the ports repository's Makefile. This way Apache uses the 'dataready' filter instead of 'httpready'. This doesn't cause any stuck connections, and it improves the performance as well because most modern browsers and proxies send the HTTP request plus the whole set of headers in a single data packet anyway, which means that unconditionally returning from accept(2) on the first data packet received is sufficient. Under these circumstances the overhead of parsing the HTTP request in the kernel, like the 'httpready' filter does, no longer makes much sense. I haven't looked at Apache 2.x so far in this regard. Perhaps there is a similar compile time option. In any case, maybe this tweak helps in your case, too. Regards, Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net