From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 17:39:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E66E916A4CE for ; Fri, 24 Sep 2004 17:39:42 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48A143D1D for ; Fri, 24 Sep 2004 17:39:41 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8OHdWI17924; Fri, 24 Sep 2004 20:39:32 +0300 Date: Fri, 24 Sep 2004 20:39:32 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8792) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2004 17:39:43 -0000 On Sat, 25 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > Apparently the most significant change is the memory consumption > regarding routing table: > > In "wrk" > Memory statistics by bucket size > Size In Use Free Requests HighWater Couldfree > 64 2196 44 5165 320 0 > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > routetbl 461 67K 67K 10148K 538 0 0 16,32,64,128,256,512 > > In "brk" > Memory statistics by bucket size > Size In Use Free Requests HighWater Couldfree > 64 37865 2583 5315047 320 1075 > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > routetbl 64959 10148K 10148K 10148K 2445306 0 0 16,32,64,128,256,512 OK.. > Some random thoughts, which may or may not help, at the moment: > > 1. do you see massive number of entries with "netstat -rna"? Yes. # netstat -nra | wc -l 32468 # A couple of examples: 2002:41a:1e23::41a:1e23 2002:c058:6301::1741 UHW3 stf0 2002:41a:1eaa::41a:1eaa 2002:c058:6301::1741 UHW3 stf0 2002:41a:6b0e::41a:6b0e 2002:c058:6301::1741 UHW3 stf0 2002:41a:6f4b::41a:6f4b 2002:c058:6301::1741 UHW3 stf0 2002:41a:70f5::41a:70f5 2002:c058:6301::1741 UHW3 stf0 1433 2002:41a:7411::41a:7411 2002:c058:6301::1741 UHW3 stf0 2002:41a:8e81::41a:8e81 2002:c058:6301::1741 UHW3 stf0 That's basically about all the 2002:xxx addresses which have been relayed through. I'd suspect the number is maxed and garbage-collected around 2^15 though, because the box is relaying w/ much many more addresses than that. I guess this provides a hint at a very probable source of leakage. > 2. if you specify the "link2" flag on the stf interface, what if you > do not specify it? (if such operation is acceptable in your > environment) The flag is not specified. > 3. if you can replace the kernel with KAME snap versions, do you see > any difference in the memory consumption? This would be a bit difficult, so I'd like to avoid it if possible. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings