| From: | Peter Avalos <pavalos@xxxxxxxxxxxx> |
| Date: | Mon, 14 Mar 2005 23:55:03 -0700 |
| Mail-followup-to: | bugs@crater.dragonflybsd.org |
On Mon, Mar 14, 2005 at 04:35:00PM -0800, Matthew Dillon wrote:
> Peter. I did some webbench tests to try to reproduce the problem, and
> I found two limitations that might have something to do with it. I
> would like you to check these two things while your machine is not responding
> to apache requests.
>
> If it turns out to be one of these two things, I don't think your issue is
> related to the firefox or opera issue.
>
> You could be:
>
> (1) Running out of sockets.
> (2) Running out of tcp ports.
>
>
> (1) Running out of sockets. Any server that accepts connections will wind
> up with the socket in a TIME_WAIT state for 2 minutes after the connection
> closes.
>
> If your kern.ipc.maxsockets is, say, 5000, then 5000 / 120 seconds ==
> only 33 connections per second before you run out of sockets.
>
> (2) Running out of tcp ports. If you are getting a lot of connections from
> the SAME IP address, the originating machine (the client you were using
> to test connections to your ftp server in this case) may run out of TCP
> ports or may start reusing ports that are still in TIME_WAIT on the
> target machine.
>
> 2 minutes to timeout it would only take 33 connections per second to run
> out of ports. But ONLY if all the connections are coming from the same IP
> address (since the limitation is based on the {ipaddress,port} tuple, not
> just the {port}).
>
> How do you tell? When you hit this situation, do this:
>
> sysctl net.inet.ip.portrange
> sysctl kern.ipc.maxsockets
> netstat -tn | wc -l
> netstat -tn | fgrep TIME_WAIT | wc -l
> netstat -m
>
> And that should tell you (and us) what is going on.
>
> If that turns out to be the case, then it probably is not related to the
> Opera/FireFox delay issue.
>
> -Matt
Next time I can reproduce the problem I'll check it out.
Thanks,
Peter
Attachment:
pgp00003.pgp
Description: PGP signature