DragonFly BSD
DragonFly bugs List (threaded) for 2005-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: ipv4 connection problems


From: Peter Avalos <pavalos@xxxxxxxxxxxx>
Date: Tue, 15 Mar 2005 00:29:02 -0700
Mail-followup-to: bugs@crater.dragonflybsd.org, dillon@apollo.backplane.com

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.
> 

Right after I had a hung telnet:

box:~% sysctl net.inet.ip.portrange
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.first: 1024
net.inet.ip.portrange.last: 5000
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.hilast: 65535
box:~% sysctl kern.ipc.maxsockets
kern.ipc.maxsockets: 12328
box:~% netstat -tn | wc -l
     229
box:~% netstat -tn | fgrep TIME_WAIT | wc -l
      25
box:~% netstat -m
1024/2278/26624 mbufs in use (current/peak/max):
        1024 mbufs allocated to data
920/1306/6656 mbuf clusters in use (current/peak/max)
3181 Kbytes allocated to network (15% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


Peter

Attachment: pgp00004.pgp
Description: PGP signature



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]