Date: Sun, 1 Nov 1998 20:39:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: toasty@home.dragondata.com (Kevin Day) Cc: dg@root.com, syang@directhit.com, opsys@mail.webspan.net, freebsd-hackers@FreeBSD.ORG Subject: Re: FW: Can't get rid of my mbufs. Message-ID: <199811012039.NAA25357@usr05.primenet.com> In-Reply-To: <199810280934.DAA05514@home.dragondata.com> from "Kevin Day" at Oct 28, 98 03:34:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >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 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL)
CLOSED
The backup is grep state 3 to state 2 -- the
<SEQ=100><ACK=300><CTL=FIN,ACK>
is resent, if the LAST-ACK takes more than 2 MSL come back.
This is precisely what would happen if the:
<SEQ=300><ACK=101><CTL=ACK>
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:
<SEQ=300><ACK=101><CTL=ACK>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811012039.NAA25357>