Date: Thu, 13 Apr 2000 13:40:02 -0700 (PDT) From: Brian Nelson <brian@pocketscience.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/17963: NATD appears to memory leak when a connection fails from the internal network to the external network. Message-ID: <200004132040.NAA23860@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/17963; it has been noted by GNATS. From: Brian Nelson <brian@pocketscience.com> To: Ruslan Ermilov <ru@ucb.crimea.ua> 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 13:34:15 -0700 Ruslan Ermilov wrote: > > 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? Yes, I am sorry, they are TCP connections. They are all connecting to americaonline.aol.com (this is DNS load-balanced) port 5190 (aol in /etc/services) The local port changes, since it's ~ 100 processes each on 7 internal machines. > > > >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? They're never established. Theyfail to successfully connect. a tcpdump shows a lot of syn's and very few fin's. The client machines are Solaris, so I am not sure how to do any TCP tuning. > > Did you try running natd(8) with -log option, and monitoring the > memory usage by `tail -f /var/log/alias.log'? I will see if I can do this. On another note, I added a ipfw rule to state all these connections, and now it's not leakign the way it was before. (ipfw add 50 allow tcp from any to any 5190 keep-state) Please note, I am not a TCP hacker, and I am learning these things as I go along. I totally appreciate your help here, friend. thank you so much. > > -- > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004132040.NAA23860>