DragonFly kernel List (threaded) for 2005-04
Re: Stable tag slipped
Matthew Dillon wrote:
:The machine doing the hammering is a Mac running MacOSX.
:[pomme:~] raphael% sysctl net.inet.tcp.msl
:[pomme:~] raphael% sysctl kern.ipc.maxsockets
:Just keep in mind there is one loop running locally on the dfbsd machine
:Why should the portrange be adjusted?
The portrange is used to select the port number to use for an outgoing
connection (it doesn't apply to incoming connections). Most programs
use the standard first - last range, which is typically around 4000 ports.
This is usually not a problem but if an originating machine is making a
lot of rapid outgoing tcp connections to the same target (e.g. the MacOSX
box making connections to a single web server), it can run out of ports
because sockets often need a cool-down time (2*MSL = 60 seconds typ)
before they can be reused. I don't know what the MSL default is on
Only one side of a TCP connection needs to go through the cooldown,
but another issue is that the side chosen depends on which side
disconnects first. And if both sides disconnect at the same time both
can wind up in TIME_WAIT.
So, for example, my own test program (which I am about to commit in
/usr/src/test/stress/webstress) is causing over 5600 sockets to be
in a TIME_WAIT state on the client and 300ish sockets in a TIME_WAIT
state on the web server. That's with the MSL reduced to 15000 mS
and net.inet.ip.portrange.last bumped up to 30000.
Under normal circumstances an HTTP session uses the HTTP/1.1 protocol
and the client does the disconnect, so TIME_WAIT sockets do not usually
build up on the server. HTTP/1.0 (old style) connections often result
in the server doing the disconnect first which often leaves it saddled
with the TIME_WAIT socket. SMTP connections to a mail server almost
universally leave the mail server saddled with the TIME_WAIT socket.
Thanks for the detailed explanation Matt.
So far, no hint of a problem on that machine, but I haven't tested the
scenario of long running tcp connections moving big files. (I have no
clue if this is relevant, I'm just guessing)
I am now looking for a way to do that without stressing too much the
disks, not to mention them being a bottleneck. I'm thinking of doing
that from a ramdisk.
by the way, will I be able to compile your webstress on MacOSX?
but for now I'm going to bed ;)