From owner-freebsd-bugs Thu Apr 13 8:10: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 01FCF37B849 for ; Thu, 13 Apr 2000 08:10:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA77423; Thu, 13 Apr 2000 08:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 13 Apr 2000 08:10:02 -0700 (PDT) Message-Id: <200004131510.IAA77423@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ruslan Ermilov Subject: Re: bin/17963: NATD appears to memory leak when a connection fails from the internal network to the external network. Reply-To: Ruslan Ermilov Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/17963; it has been noted by GNATS. From: Ruslan Ermilov To: brian@pocketscience.com Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: bin/17963: NATD appears to memory leak when a connection fails from the internal network to the external network. Date: Thu, 13 Apr 2000 18:04:38 +0300 On Wed, Apr 12, 2000 at 07:18:39PM -0700, brian@pocketscience.com wrote: > > In production, we are making several connection attempts to do AOL > polling. Some are getting a failure to connect (actually, a > significant number are). Since we have noticed this behavior (a bug > on our end), we have also noticed that natd memory leaks, actually > pretty significantly. > > We're pulling ~50k connections/hour. It takes ~16 hours for the > daemon to leak enough that the network dies on the machine, until > you restart natd. > Are these TCP connections? (I will assume that they are below). Are these connections to the same remote machine/port? Are these connections from the same local machine/port? > >How-To-Repeat: > Set up natd. > > from an internal machine, make several network connections that get > dropped on the remote end (not denied, but connection timeouts) > It is unclear what do you mean. Do these connections get established, and then single-dropped by the remote end, or not established at all? In the first case, turning on and tuning a system-wide TCP keepalive on the client side might help. Do you have it enabled? What are the values of net.inet.tcp.*keep* MIB variables? Did you try running natd(8) with -log option, and monitoring the memory usage by `tail -f /var/log/alias.log'? -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message