|
List Info
Thread: Should syncache.count ever be negative?
|
|
| Should syncache.count ever be negative? |
|
2007-11-09 18:09:06 |
On a eight core machine running RELENG_7 I'm seeing TCP
stalls,
sometimes lasting up to 60 seconds or so. While trying to
track this
down I noticed that net.inet.tcp.syncache.count is negative.
Should it
be possible for the count to go negative? Perhaps it
indicates a race,
or the counter is wrongly being decremented twice?
Matt
# sysctl net.inet.tcp.syncache
net.inet.tcp.syncache.rst_on_sock_fail: 1
net.inet.tcp.syncache.rexmtlimit: 3
net.inet.tcp.syncache.hashsize: 512
net.inet.tcp.syncache.count: -97
net.inet.tcp.syncache.cachelimit: 15360
net.inet.tcp.syncache.bucketlimit: 30
_______________________________________________
freebsd-net freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| Re: Should syncache.count ever be
negative? |
|
2007-11-09 21:46:21 |
On Fri, 9 Nov 2007, Matt Reimer wrote:
> On a eight core machine running RELENG_7 I'm seeing TCP
stalls,
> sometimes lasting up to 60 seconds or so. While trying
to track this
> down I noticed that net.inet.tcp.syncache.count is
negative. Should it
> be possible for the count to go negative? Perhaps it
indicates a race,
> or the counter is wrongly being decremented twice?
I just took a look at the code, and you are correct that the
count is not
locked; it looks like you're hitting the race. However, it
doesn't look
like anything is checking the count, so that should not be
the cause of
your TCP stalls.
Can you install netperf and run both the TCP_STREAM and
UDP_STREAM tests
just to make sure that your network card is working
properly? We've
recently found that the fast interrupt handlers we use in
some network
drivers act strangely when sharing interrupts. So, that's a
first thing
to test before we poke at the upper layers.
If that doesn't help, can you post more details about how
you are
stressing the system?
Thanks,
-Mike
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| Re: Should syncache.count ever be
negative? |
|
2007-11-10 01:23:31 |
On Nov 9, 2007 7:46 PM, Mike Silbersack <silbysilby.com> wrote:
>
> On Fri, 9 Nov 2007, Matt Reimer wrote:
>
> > On a eight core machine running RELENG_7 I'm
seeing TCP stalls,
> > sometimes lasting up to 60 seconds or so. While
trying to track this
> > down I noticed that net.inet.tcp.syncache.count is
negative. Should it
> > be possible for the count to go negative? Perhaps
it indicates a race,
> > or the counter is wrongly being decremented
twice?
>
> I just took a look at the code, and you are correct
that the count is not
> locked; it looks like you're hitting the race.
However, it doesn't look
> like anything is checking the count, so that should not
be the cause of
> your TCP stalls.
Yeah, that's the conclusion I came to also.
> Can you install netperf and run both the TCP_STREAM and
UDP_STREAM tests
> just to make sure that your network card is working
properly? We've
> recently found that the fast interrupt handlers we use
in some network
> drivers act strangely when sharing interrupts. So,
that's a first thing
> to test before we poke at the upper layers.
Ok, I've run netperf in both directions. The box I've been
targeting
is 66.230.193.105 aka wordpress1.
[rootwordpress2 ~]# netperf -p 5000 -t TCP_STREAM -H
66.230.193.105
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
66.230.193.105 (66.230.193.105) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
65536 32768 32768 10.03 93.00
[rootwordpress2 ~]# netperf -p 5000 -t UDP_STREAM -H
66.230.193.105
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0
AF_INET to
66.230.193.105 (66.230.193.105) port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
9216 9216 10.01 13145 2588457 96.81
41600 10.01 13145 96.81
[rootwordpress1 ~]# netperf -H 66.230.193.106 -p 5000 -t
TCP_STREAM
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
66.230.193.106 (66.230.193.106) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
65536 32768 32768 10.02 94.03
[rootwordpress1 ~]# netperf -H 66.230.193.106 -p 5000 -t
UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0
AF_INET to
66.230.193.106 (66.230.193.106) port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
9216 9216 10.00 13151 2532692 96.95
41600 10.00 13135 96.83
> If that doesn't help, can you post more details about
how you are
> stressing the system?
Yes, I'll get you whatever information you want.
The machine is a Dell 1950 with 8 x 1.6GHz Xeon 5310s, 8G
RAM, and this NIC:
bce0pci0:9:0:0: class=0x020000 card=0x01b31028
chip=0x164c14e4 rev=0x12
hdr=0x00
vendor = 'Broadcom Corporation'
device = '5708C Broadcom NetXtreme II Gigabit
Ethernet Adapter'
class = network
subclass = ethernet
[rootwordpress1 ~]# ifconfig bce0
bce0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
metric 0 mtu 1500
options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_M
TU,VLAN_HWCSUM,TSO4>
ether 00:19:b9:ea:99:a4
inet 66.230.193.105 netmask 0xffffff00 broadcast
66.230.193.255
media: Ethernet autoselect (100baseTX
<full-duplex>)
status: active
I first noticed this problem running ab; then to simplify I
used
netrate/http[d]. What's strange is that it seems fine over
the local
network (~15800 requests/sec), but it slowed down
dramatically (~150
req/sec) when tested from another network 20 ms away.
Running systat
-tcp and nload I saw that there was an almost complete stall
with only
a handful of packets being sent (probably my ssh packets)
for a few
seconds or sometimes even up to 60 seconds or so.
Next I turned on net.inet.tcp.log_debug and ran tcpdump
while running
ab against netrate/http. Then I looked at the tcpdump
capture and
looked for a gap in the timestamps when the traffic seemed
stalled. I
saw that other packets were coming in and going out (e.g.
multicast
and ARP traffic) but little TCP traffic. From there I looked
backwards
for the TCP traffic leading up to the stall and saw a
strange exchange
on the packets with source port 64851 (and others, but I'll
stick with
this one for illustration):
SYN
SYN-ACK
ACK
RST
RST
Looking at the logs I saw:
Nov 9 19:02:34 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80; syncache_socket: Socket create failed
due to
limits or memory shortage
Nov 9 19:02:34 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80 tcpflags 0x10<ACK>; tcp_input:
Listen socket:
Socket allocation failed due to limits or memory shortage,
sending RST
Nov 9 19:02:34 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80; syncache_socket: Socket create failed
due to
limits or memory shortage
Nov 9 19:02:34 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80 tcpflags 0x18<PUSH,ACK>;
tcp_input: Listen socket:
Socket allocation failed due to limits or memory shortage,
sending RST
But it doesn't seem to be a memory shortage; vmstat -z
during one of
those stalls shows:
socket: 696, 12330, 14, 3861,
14786330, 0
unpcb: 248, 12330, 6, 1149,
6052662, 0
ipq: 56, 819, 0, 0,
0, 0
udpcb: 280, 12334, 2, 222,
1531, 0
inpcb: 280, 12334, 2271, 2671,
8732131, 0
tcpcb: 688, 12330, 6, 2304,
8732131, 0
tcptw: 88, 2478, 2265, 213,
201553, 6438776
syncache: 112, 15378, 2, 823,
7197735, 0
hostcache: 136, 15372, 0, 112,
19, 0
tcpreass: 40, 1680, 0, 672,
50, 0
Corresponding to these error messages there are two RST
packets around
14.528 seconds into the tcpdump. Looking at the code it
seems that
what must be happening is that syncache_expand() fails
somehow,
leaving 'so' NULL. Wireshark shows that:
SYN
SYN-ACK
ACK
kernel tries to set up the socket; syncache_expand()
fails, so
it sends...
RST
but the sending host already saw a SYN-ACK so it
sends...
"GET /short.html..."
kernel replies with another RST since the socket
allocation failed
So I looked at the logs again and saw that the same thing
happens
again, 97 seconds later, and then again 103 seconds after
that. The
sequence of SYNs etc. is identical:
Nov 9 19:04:11 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80; syncache_socket: Socket create failed
due to
limits or memory shortage
Nov 9 19:04:11 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80 tcpflags 0x10<ACK>; tcp_input:
Listen socket:
Socket allocation failed due to limits or memory shortage,
sending RST
Nov 9 19:04:11 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80; syncache_socket: Socket create failed
due to
limits or memory shortage
Nov 9 19:04:11 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80 tcpflags 0x18<PUSH,ACK>;
tcp_input: Listen socket:
Socket allocation failed due to limits or memory shortage,
sending RST
And:
Nov 9 19:05:55 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80; syncache_socket: Socket create failed
due to
limits or memory shortage
Nov 9 19:05:55 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80 tcpflags 0x10<ACK>; tcp_input:
Listen socket:
Socket allocation failed due to limits or memory shortage,
sending RST
Nov 9 19:05:55 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80; syncache_socket: Socket create failed
due to
limits or memory shortage
Nov 9 19:05:55 wordpress1 kernel: TCP: [207.210.67.2]:64851
to
[66.230.193.105]:80 tcpflags 0x18<PUSH,ACK>;
tcp_input: Listen socket:
Socket allocation failed due to limits or memory shortage,
sending RST
It seems very fishy that a socket allocation for this port
64851
should fail three times in less than four minutes, when
other
allocations succeed. Why are these socket creations failing,
and
consistently failing for the same port numbers?
I don't know if it's relevant, but accf_http is loaded on
wordpress1.
We have seen similar behavior (TCP slowdowns) on a different
machines
(4 x Xeon 5160) with a different NIC (em0) running RELENG_7,
though I
haven't diagnosed it to this level of detail. All our
RELENG_6 and
RELENG_4 machines seem fine.
An excerpt from the full tcpdump is available at
http://bi
lbo.vpop.net/~mreimer/tcpdump.bad; I'll make the full
14M
dump available upon request. I'll run whatever tests are
needed, add
debugging printf's, etc.
Thanks for your help.
Matt
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| Re: Should syncache.count ever be
negative? |
|
2007-11-10 02:13:22 |
On Fri, 9 Nov 2007, Matt Reimer wrote:
> Ok, I've run netperf in both directions. The box I've
been targeting
> is 66.230.193.105 aka wordpress1.
Ok, at least that looks good.
> The machine is a Dell 1950 with 8 x 1.6GHz Xeon 5310s,
8G RAM, and this NIC:
Nice.
> I first noticed this problem running ab; then to
simplify I used
> netrate/http[d]. What's strange is that it seems fine
over the local
> network (~15800 requests/sec), but it slowed down
dramatically (~150
> req/sec) when tested from another network 20 ms away.
Running systat
> -tcp and nload I saw that there was an almost complete
stall with only
> a handful of packets being sent (probably my ssh
packets) for a few
> seconds or sometimes even up to 60 seconds or so.
I think most benchmarking tools end up stalling if all of
their threads
stall, that may be why the rate falls off after the
misbehavior you
describe below begins.
> Nov 9 19:02:34 wordpress1 kernel: TCP:
[207.210.67.2]:64851 to
> [66.230.193.105]:80; syncache_socket: Socket create
failed due to
> limits or memory shortage
> Nov 9 19:02:34 wordpress1 kernel: TCP:
[207.210.67.2]:64851 to
> [66.230.193.105]:80 tcpflags 0x10<ACK>;
tcp_input: Listen socket:
> Socket allocation failed due to limits or memory
shortage, sending RST
Turns out you'll generally get both of those error messages
together, from
my reading of the code.
Since you eliminated memory shortage in the socket zone, the
next thing to
check is the length of the listen queues. If the listen
queue is backing
up because the application isn't accepting fast enough, the
errors above
should happen. "netstat -Lan" should show you
what's going on there.
Upping the specified listen queue length in your webserver
_may_ be all
that is necessary. Try fiddling with that and watching how
much they're
filling up during testing.
The fact that you see the same port repeatedly may indicate
that the
syncache isn't destroying the syncache entries when you get
the socket
creation failure. Take a look at "netstat -n" and
look for SYN_RECEIVED
entries - if they're sticking around for more than a few
seconds, this is
probably what's happening. (This entire paragraph is
speculation, but
worth investigating.)
> I don't know if it's relevant, but accf_http is loaded
on wordpress1.
That may be relevant - accepting filtering changes how the
listen queues
are used. Try going back to non-accept filtering for now.
> We have seen similar behavior (TCP slowdowns) on a
different machines
> (4 x Xeon 5160) with a different NIC (em0) running
RELENG_7, though I
> haven't diagnosed it to this level of detail. All our
RELENG_6 and
> RELENG_4 machines seem fine.
em is the driver that I was having issues with when it
shared an
interrupt... 
FWIW, my crazy theory of the moment is this: We have some
bug that
happens when the listen queues overflow in 7.0, and your
test is strenuous
enough to hit the listen queue overflow condition, leading
to total
collapse. I'll have to cobble together a test program to
see what happens
in the listen queue overflow case.
Thanks for the quick feedback,
-Mike
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| Re: Should syncache.count ever be
negative? |
|
2007-11-10 03:13:11 |
On Nov 10, 2007 12:13 AM, Mike Silbersack <silbysilby.com> wrote:
>
> On Fri, 9 Nov 2007, Matt Reimer wrote:
>
> > I first noticed this problem running ab; then to
simplify I used
> > netrate/http[d]. What's strange is that it seems
fine over the local
> > network (~15800 requests/sec), but it slowed down
dramatically (~150
> > req/sec) when tested from another network 20 ms
away. Running systat
> > -tcp and nload I saw that there was an almost
complete stall with only
> > a handful of packets being sent (probably my ssh
packets) for a few
> > seconds or sometimes even up to 60 seconds or so.
>
> I think most benchmarking tools end up stalling if all
of their threads
> stall, that may be why the rate falls off after the
misbehavior you
> describe below begins.
Ok. FWIW, I'm seeing the same behavior with
tools/netrate/http as I am with ab.
> > Nov 9 19:02:34 wordpress1 kernel: TCP:
[207.210.67.2]:64851 to
> > [66.230.193.105]:80; syncache_socket: Socket
create failed due to
> > limits or memory shortage
> > Nov 9 19:02:34 wordpress1 kernel: TCP:
[207.210.67.2]:64851 to
> > [66.230.193.105]:80 tcpflags 0x10<ACK>;
tcp_input: Listen socket:
> > Socket allocation failed due to limits or memory
shortage, sending RST
>
> Turns out you'll generally get both of those error
messages together, from
> my reading of the code.
>
> Since you eliminated memory shortage in the socket
zone, the next thing to
> check is the length of the listen queues. If the
listen queue is backing
> up because the application isn't accepting fast enough,
the errors above
> should happen. "netstat -Lan" should show
you what's going on there.
> Upping the specified listen queue length in your
webserver _may_ be all
> that is necessary. Try fiddling with that and watching
how much they're
> filling up during testing.
I ran "netstat -Lan" every second while running
this test and the
output never changed from the following, whether before or
after the
stall:
Current listen queue sizes (qlen/incqlen/maxqlen)
Proto Listen Local Address
tcp4 0/0/128 66.230.193.105.80
tcp4 0/0/10 127.0.0.1.25
tcp4 0/0/128 *.22
tcp4 0/0/128 *.199
> The fact that you see the same port repeatedly may
indicate that the
> syncache isn't destroying the syncache entries when you
get the socket
> creation failure. Take a look at "netstat
-n" and look for SYN_RECEIVED
> entries - if they're sticking around for more than a
few seconds, this is
> probably what's happening. (This entire paragraph is
speculation, but
> worth investigating.)
During the stall the sockets are all in TIME_WAIT. More
relevant info:
kern.ipc.maxsockets: 12328
kern.ipc.numopensockets: 46
net.inet.ip.portrange.randomtime: 45
net.inet.ip.portrange.randomcps: 10
net.inet.ip.portrange.randomized: 1
net.inet.ip.portrange.reservedlow: 0
net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.hilast: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.first: 30000
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.lowfirst: 1023
net.inet.tcp.finwait2_timeout: 60000
net.inet.tcp.fast_finwait2_recycle: 0
[rootwordpress1 /sys/dev]# netstat -m
513/5382/5895 mbufs in use (current/cache/total)
511/3341/3852/25600 mbuf clusters in use
(current/cache/total/max)
1/1663 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/488/488/0 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
1150K/9979K/11129K bytes allocated to network
(current/cache/total)
0/0/0 requests for mbufs denied
(mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
17 requests for I/O initiated by sendfile
0 calls to protocol drain routines
> > I don't know if it's relevant, but accf_http is
loaded on wordpress1.
>
> That may be relevant - accepting filtering changes how
the listen queues
> are used. Try going back to non-accept filtering for
now.
It still stalls. This time I noticed that tcptw shows 0
free:
socket: 696, 12330, 14, 126,
10749, 0
unpcb: 248, 12330, 5, 70,
75, 0
ipq: 56, 819, 0, 0,
0, 0
udpcb: 280, 12334, 2, 40,
184, 0
inpcb: 280, 12334, 2485, 105,
10489, 0
tcpcb: 688, 12330, 7, 73,
10489, 0
tcptw: 88, 2478, 2478, 0,
2478, 7231
syncache: 112, 15378, 1, 65,
9713, 0
hostcache: 136, 15372, 0, 0,
0, 0
tcpreass: 40, 1680, 0, 0,
0, 0
sackhole: 32, 0, 0, 0,
0, 0
But even while tcptw shows 0 free, I can still blast 15800
req/s from
another RELENG_7 box to this one during the stall. So I
don't know if
that means anything.
> FWIW, my crazy theory of the moment is this: We have
some bug that
> happens when the listen queues overflow in 7.0, and
your test is strenuous
> enough to hit the listen queue overflow condition,
leading to total
> collapse. I'll have to cobble together a test program
to see what happens
> in the listen queue overflow case.
When I use ab I'm telling it to use a max of 100
simultaneous
connections (ab -c 100 -n 50000 http://66.230.193.105/).
Wouldn't that
be well under the limit?
> Thanks for the quick feedback,
Thank *you*.
Matt
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| Re: Should syncache.count ever be
negative? |
|
2007-11-10 03:36:57 |
On Sat, 10 Nov 2007, Mike Silbersack wrote:
> FWIW, my crazy theory of the moment is this: We have
some bug that happens
> when the listen queues overflow in 7.0, and your test
is strenuous enough to
> hit the listen queue overflow condition, leading to
total collapse. I'll
> have to cobble together a test program to see what
happens in the listen
> queue overflow case.
Post testing, I have a different theory.
Can you also try
sysctl net.inet.tcp.syncookies=0
I modified netrate's httpd to sleep a lot and found an
interesting
behavior between listen queue overflows and syncookies:
04:28:21.470931 IP 10.1.1.8.50566 > 10.1.1.6.http: S
287310302:287310302(0) win 32768 <mss 1460,nop,wscale
0,nop,nop,timestamp 3293131923 0,sackOK,eol>
04:28:21.470939 IP 10.1.1.6.http > 10.1.1.8.50566: S
4209413098:4209413098(0) ack 287310303 win 65535 <mss
1460,nop,wscale 3,nop,nop,timestamp 1264205330
3293131923>
04:28:21.473487 IP 10.1.1.8.50566 > 10.1.1.6.http: . ack
1 win 33304 <nop,nop,timestamp 3293131926 1264205330>
04:28:21.473493 IP 10.1.1.6.http > 10.1.1.8.50566: R
4209413099:4209413099(0) win 0
04:28:21.473642 IP 10.1.1.8.50566 > 10.1.1.6.http: P
1:78(77) ack 1 win 33304 <nop,nop,timestamp 3293131926
1264205330>
04:28:21.482555 IP 10.1.1.6.http > 10.1.1.8.50566: P
1:126(125) ack 78 win 8326 <nop,nop,timestamp 1264205339
3293131926>
04:28:21.482563 IP 10.1.1.6.http > 10.1.1.8.50566: F
126:126(0) ack 78 win 8326 <nop,nop,timestamp 1264205339
3293131926>
04:28:21.487047 IP 10.1.1.8.50566 > 10.1.1.6.http: R
287310380:287310380(0) win 0
04:28:21.487398 IP 10.1.1.8.50566 > 10.1.1.6.http: R
287310380:287310380(0) win 0
The listen queue overflow causes the socket to be closed and
a RST sent,
but the next packet from 10.1.1.8 crosses it on the wire and
activates the
syncookie code, reopening the connection. Meanwhile, the
RST arrives at
10.1.1.8 and closes its socket, leading to it sending RSTs
when the data
from 10.1.1.6 arrives.
Not sure if that's your problem or not, but it's
interesting.
-Mike
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
| Re: Should syncache.count ever be
negative? |
|
2007-11-10 03:40:38 |
On Sat, 10 Nov 2007, Matt Reimer wrote:
> I ran "netstat -Lan" every second while
running this test and the
> output never changed from the following, whether before
or after the
> stall:
I forgot to mention, check netstat -s for listen queue
overflows.
> During the stall the sockets are all in TIME_WAIT. More
relevant info:
In the past that was not a problem, but I should retest this
as well.
> It still stalls. This time I noticed that tcptw shows 0
free:
The tcptw zone is supposed to fill completely, then kick out
the oldest
entry whenever a new one comes in. So, that sounds ok to
me... but like I
said, I need to retest that too.
> When I use ab I'm telling it to use a max of 100
simultaneous
> connections (ab -c 100 -n 50000 http://66.230.193.105/).
Wouldn't that
> be well under the limit?
Yep, should be. Hmph.
-Mike
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
|
[1-7]
|
|