From owner-freebsd-current@FreeBSD.ORG Sun Jan 27 14:29:21 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EF516A41A for ; Sun, 27 Jan 2008 14:29:21 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id F216F13C4D5 for ; Sun, 27 Jan 2008 14:29:20 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 534601B10EE0; Sun, 27 Jan 2008 15:29:19 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_52 autolearn=no version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id C4B591B10C26; Sun, 27 Jan 2008 15:29:16 +0100 (CET) Message-ID: <479C953C.1010304@moneybookers.com> Date: Sun, 27 Jan 2008 16:29:16 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Max Laier References: <479A2389.2000802@moneybookers.com> <200801262227.36970.max@love2party.net> <479C4F31.7090804@moneybookers.com> <200801271422.23340.max@love2party.net> In-Reply-To: <200801271422.23340.max@love2party.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5574/Sun Jan 27 11:03:42 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7, bridge, PF and syn flood = very bad performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 14:29:21 -0000 Greetings, Max Laier wrote: -cut- >> Well I think the interesting lines from this experiment are: >> max total wait_total count avg >> wait_avg cnt_hold cnt_lock name >> 39 25328476 70950955 9015860 2 7 >> 5854948 6309848 /usr/src/sys/contrib/pf/net/pf.c:6729 (sleep >> mutex:pf task mtx) >> 936935 10645209 350 50 212904 7 >> 110 47 /usr/src/sys/contrib/pf/net/pf.c:980 (sleep mutex:pf >> task mtx) >> > > Yeah, those two mostly are the culprit, but a quick fix is not really > available. You can try to "set timeout interval" to something bigger > (e.g. 60 seconds) which will decrease the average hold time of the second > lock instance at the cost of increased peak memory usage. > I'll try and this. At least memory doesn't seems to be a problem :) > I have the ideas how to fix this, but it will take much much more time > than I currently have for FreeBSD :-\ In general this requires a bottom > up redesign of pf locking and some data structures involved in the state > tree handling. > > The first(=main) lock instance is also far from optimal (i.e. pf is a > congestion point in the bridge forwarding path). For this I have also a > plan how to make at least state table lookups run in parallel to some > extend, but again the lack of free time to spend coding prevents me from > doing it at the moment :-\ > Well, now we know where the issue is. The same problem seems to affect synproxy state btw. Can I expect better performance with IPFW's dynamic rules? I wonder how one can protect himself on gigabit network and service more then 500pps. For example in my test lab I see incoming ~400k packets per second, but if I activate PF, I see only 130-140k packets per second. Is this expected behavior, if PF cannot handle so many packets? The missing 250k+ are not listed as discarded or other errors, which is weird. -- Best Wishes, Stefan Lambrev ICQ# 24134177