From owner-freebsd-hackers Sun Nov 1 12:39:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03082 for freebsd-hackers-outgoing; Sun, 1 Nov 1998 12:39:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03075 for ; Sun, 1 Nov 1998 12:39:21 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id NAA10826; Sun, 1 Nov 1998 13:39:15 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd010776; Sun Nov 1 13:39:09 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA25357; Sun, 1 Nov 1998 13:39:01 -0700 (MST) From: Terry Lambert Message-Id: <199811012039.NAA25357@usr05.primenet.com> Subject: Re: FW: Can't get rid of my mbufs. To: toasty@home.dragondata.com (Kevin Day) Date: Sun, 1 Nov 1998 20:39:01 +0000 (GMT) Cc: dg@root.com, syang@directhit.com, opsys@mail.webspan.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199810280934.DAA05514@home.dragondata.com> from "Kevin Day" at Oct 28, 98 03:34:24 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >Thanks for the info. One question remains. Suppose netstat -m tells me > > >that 7900/8050 mbuf clusters are in use. Now suppose I stop all of the > > >important processes and let the machine stay idle for 2 hours. Why does > > >netstat -m still tell me that 7900/8050 mbuf clusters are in use? > > >Basically, I'd wish it would say something like 99/8050 mbuf clusters in > > >use instead. I already have MAXUSERS set to 512. > > > > What does "netstat -n" show? > > > > For what it's worth.... I've got something similar.... [ ... lot of FIN_WAIT_2 to port 80 ... ] You have WinSock clients which are failing to call shutdown() before closing the socket. These clients are in error. There is a design flaw in the TCP/IP protocol, in that it has a case where a single request is supposed to elicit two responses: one for FIN_WAIT_1, and the second for FIN_WAIT_2. NT gets around this problem by pretending that it did not get the first response (an ACK); basically, it backs up, and potentially reenters FIN_WAIT_2 2 MSL later. This happens when the server does the close first. From RFC 793: TCP A TCP B 1. ESTABLISHED ESTABLISHED 2. (Close) FIN-WAIT-1 --> --> CLOSE-WAIT 3. FIN-WAIT-2 <-- <-- CLOSE-WAIT 4. (Close) TIME-WAIT <-- <-- LAST-ACK 5. TIME-WAIT --> --> CLOSED 6. (2 MSL) CLOSED The backup is grep state 3 to state 2 -- the is resent, if the LAST-ACK takes more than 2 MSL come back. This is precisely what would happen if the: was lost. If the remote side has no record of the connection (since it has disassembled it without a shutdown() before the close()), then the TCP A will get an RST, and should act as if a successful close had occurred. If the remote side still has a record of the connection, then the: Is resent, and the TCP A goes back to sleep for another 2 MSL. In this way, the protocol design flaw is worked around. I have suggested for a number of months now (actually, 13 of them) that FreeBSD should have a sysctl for NT_bug_compatible to turn on this behaviour, and that the current FIN-WAIT-2 discard clock is, in fact, an *error*, since it allows the discard of valid connections with extrememely long drain delays -- which may be legitimate natural phenomenon. A secondary problem is that you appear to have a hell of a lot of DNS LISTEN's going on, but since this may be intentional, I'll refrain from commenting one them further. For a workaround for the first problem, you should delay the server close of the HTTP connection for at least 4 MSL, such that the shutdown is initiated by the client instead. In general, a "sleep( 2);" before the socket close will suffice for this purpose for most clients. You may want to consider unsetting the SO_LINGER, which is intended to allow a drain-to-client after close, in combination with the sleep. Note that if the client drain takes more than 2 seconds, clients may be presented with incomplete HTML documents, if you do this (which is why the FIN-WAIT-2 state exists in the first place). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message