From owner-freebsd-net@FreeBSD.ORG Mon May 24 02:54:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEAB21065670 for ; Mon, 24 May 2010 02:54:38 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 936368FC0C for ; Mon, 24 May 2010 02:54:38 +0000 (UTC) Received: by iwn5 with SMTP id 5so3405390iwn.13 for ; Sun, 23 May 2010 19:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O7kHjMgjks4qNw+HIXRP5RsqvA22+M7x7h78Etyg1o4=; b=cTk9peTy06SiLXrWPK8D5ewYP1tECDLrNSoZaaT7dDftTZFal9/8xyAu1zYN2j2Dgb y6umPiTgxVWScfIjaQR97DMFfCteXL66LmudwyIG21Rbi4OejdN2jE9wXNzy4xAapk2F RVo4tcaa5SQHWztL6KElhqsziG7s9Ugtog8dU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g6i1ac6Kc0gW109mVkamIVn5X0VGPfKdi3tyF5B7CVZYkfVvR6O+DJKtn+hemhG31B yFTGKSHC88CA+ehm3vciT+KcDfN/ateXffiA1QgwkWKXBKjYGLr8Oz3JWeJp2G2fuHK9 sQzIHWlbkp4HdrW4WWUMzci2nmZXozcAmqvyU= MIME-Version: 1.0 Received: by 10.231.156.1 with SMTP id u1mr4452663ibw.46.1274669676817; Sun, 23 May 2010 19:54:36 -0700 (PDT) Received: by 10.231.182.204 with HTTP; Sun, 23 May 2010 19:54:36 -0700 (PDT) In-Reply-To: <201005232206.o4NM6gor016873@freefall.freebsd.org> References: <201005232206.o4NM6gor016873@freefall.freebsd.org> Date: Sun, 23 May 2010 21:54:36 -0500 Message-ID: From: Brandon Gooch To: Kurt Jaeger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Kip Macy Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 02:54:39 -0000 On Sun, May 23, 2010 at 5:06 PM, Kurt Jaeger wrote: > The following reply was made to PR kern/146792; it has been noted by GNAT= S. > > From: Kurt Jaeger > To: bug-followup@FreeBSD.org, niko@gtelecom.ru > Cc: > Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load > Date: Sun, 23 May 2010 16:19:25 +0200 > > =A0Hi! > > =A0I observe a similar behaviour on a 8.0-RELEASE-p2 i386 GENERIC > =A0kernel. > > =A0System receives 2 BGP4 fullfeeds (approx. 310K routes each). > > =A0The system is still running, a few processes are unkillable or > =A0die only after a long amount (1-2h) of time. > > =A0Here's the list of unkillable processes: > > =A080871 =A0?? =A0R =A0 =A0 =A00:00.00 /bin/sh /etc/periodic/daily/470.st= atus-named > =A076499 =A0?? =A0Rs =A0 =A0 0:00.01 sshd: [accepted] (sshd) > =A076922 =A0?? =A0Rs =A0 =A0 0:00.01 sshd: [accepted] (sshd) > > =A0flowcleaner looks pretty busy (for an uptime of approx. 40h): > > =A0 =A022 =A0?? =A0RL =A0 1209:50.98 [flowcleaner] > > =A04:17PM =A0up 1 day, 22:22, 2 users, load averages: 7.20, 6.53, 5.81 > > =A0quagga is running on the system, bgpd mgmt cli is no longer reachable: > > =A0# telnet 0 2605 > =A0Trying 0.0.0.0... > =A0Connected to 0. > =A0Escape character is '^]'. > > =A0^] > =A0telnet> close > =A0Connection closed. > =A0# > > =A0What can I do to help to debug this ? > =A0No console access available right now, but can probably made available= . > > =A0This is a production host, but not yet super-critical, so... I know absolutely nothing about quagga, and very, very little about the flowcleaner process (or flowtable, no man page), but I DO KNOW that Kip Macy suggested disabling: options FLOWTABLE from the kernel config of the machine experiencing the issue. This was back in December 2009, so I'm not sure about a resolution to the actual problem (or if it is just inherent in the design of the per-cpu routing cache). Perhaps Kip may have more insight? -Brandon