kern/146792: [flowtable] flowcleaner 100% cpu's core load

[K. Macy]

This has since been fixed. However, with 8.0 the simplest fix is to
turn flowtable off.

sysctl net.inet.flowtable.enable=0

-Kip

On Mon, May 24, 2010 at 4:54 AM, Brandon Gooch
<jamesbrandongooch at gmail.com> wrote:
> On Sun, May 23, 2010 at 5:06 PM, Kurt Jaeger <pi at opsec.eu> wrote:
>> The following reply was made to PR kern/146792; it has been noted by GNATS.
>>
>> From: Kurt Jaeger <pi at opsec.eu>
>> To: bug-followup at FreeBSD.org, niko at gtelecom.ru
>> Cc:
>> Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load
>> Date: Sun, 23 May 2010 16:19:25 +0200
>>
>>  Hi!
>>
>>  I observe a similar behaviour on a 8.0-RELEASE-p2 i386 GENERIC
>>  kernel.
>>
>>  System receives 2 BGP4 fullfeeds (approx. 310K routes each).
>>
>>  The system is still running, a few processes are unkillable or
>>  die only after a long amount (1-2h) of time.
>>
>>  Here's the list of unkillable processes:
>>
>>  80871  ??  R      0:00.00 /bin/sh /etc/periodic/daily/470.status-named
>>  76499  ??  Rs     0:00.01 sshd: [accepted] (sshd)
>>  76922  ??  Rs     0:00.01 sshd: [accepted] (sshd)
>>
>>  flowcleaner looks pretty busy (for an uptime of approx. 40h):
>>
>>    22  ??  RL   1209:50.98 [flowcleaner]
>>
>>  4:17PM  up 1 day, 22:22, 2 users, load averages: 7.20, 6.53, 5.81
>>
>>  quagga is running on the system, bgpd mgmt cli is no longer reachable:
>>
>>  # telnet 0 2605
>>  Trying 0.0.0.0...
>>  Connected to 0.
>>  Escape character is '^]'.
>>
>>  ^]
>>  telnet> close
>>  Connection closed.
>>  #
>>
>>  What can I do to help to debug this ?
>>  No console access available right now, but can probably made available.
>>
>>  This 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
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>