ipv4 connection problems

Peter Avalos pavalos at theshell.com
Mon Mar 14 23:29:32 PST 2005


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00004.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20050314/1675020b/attachment-0022.obj>


More information about the Bugs mailing list