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:56:28 -0700
Mail-followup-to: bugs@crater.dragonflybsd.org, dillon@apollo.backplane.com

On Mon, Mar 14, 2005 at 11:35:54PM -0800, Matthew Dillon wrote:
> 
> :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
> 
>     It does not appear to be hitting any limits.  Check your 'dmesg' output,
>     are you getting a packet rate warnings?  In particular RST rate 
>     warnings?
 
No.

>     Also check your apache configuration... how many simultanious connections
>     is it configured to handle?  You have ~229-25 active connections and
>     I think by default Apache only handles 150.  I don't know what
>     percentage of those connections are to port 80 and what are to other
>     ports, but it's definitely a possible suspect.
 
Only 42 of those are http connections.  Definitely not hitting an Apache limit
there.  Keep in mind too, I've been able to duplicate this behavior with ftp
and smtp.

>     If it isn't an apache configuration issue then all I can think of is
>     to ctl-alt-esc and panic the machine while telnet is in this state and 
>     get the vmcore and kernel to us, we might be able to figure out what
>     is going on post-mortem.
 
This will be tricky since I'm about 7100 miles from the machine right now,
but if I can arrange it, I'll do it.

--Peter

Attachment: pgp00005.pgp
Description: PGP signature



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