H. Willstrand wrote:
On Tue, Apr 1, 2008 at 5:43 PM, Gabriel Barazer <gabriel@xxxxxxxx> wrote:
On 04/01/2008 4:43:20 PM +0200, Brett Paden <paden@xxxxxxxxxxxx> wrote:
>> If I'm right Brett's problem relays in the test client (provided in
>> the first mail). This has probably to do with the number of ports
>> opened and closed during a short time period.
>
> My test client is designed to simulate the sort of load our production
> databases and web servers see. We're talking on the order of 100-400
> connections per second. On an unloaded server the 3000ms occur right
> around 400 connections a second but we have seen them a lower connection
> rates. Are you suggesting that we could do something simple (like reap
> TIME_WAIT connections) to allevaite the problem?
Using tcp_tw_recycle / tcp_tw_reuse doesn't solve the problem either on
the client nor on the server. I tested with and without these options
enabled, disabled netfilter's connection tracking and none solved this
delay. If even the "lo" interface is concerned, there is definitely
something into the network stack and not the device drivers.
Here is a thread I started on LKML about this very same bug.
http://lkml.org/lkml/2008/3/14/353
There is a forum thread with french hosting providers talking about it.
(if some of you read french:
http://www.webmasterclub.fr/forum/topic,59486,0.html)
We are far from being alone!
Welcome to the club, Gabriel!
Gabriel
Ok, seams to be the same issue that Leo has (has nothing to do with
the Brett / Marlon issue, only common dominator is the 3000ms).
But Gabriel is also talking about 3 second timeouts on the client as
Brett and I did. I have read Gabriel's description on the provided link
and it seems to be exactly the same problem. I think Brett can confirm
this ...
This issue is probably caused by server delivering as miscalculated
SYN/ACK (the acked number is miscalculated, see my second mail).
When you look at my first tcpdump with two machines as server and client
then you can see that there are no miscalculated SYN/ACK packets from
the server (and therefore no RST packet from the client). All packets
have the right number but the client never receives the SYN/ACK packet
from the server. Only at the lo test there are RST packets and wrong
packet numbers. But as I told you in my last email I think this is a
different problem and not important for us. We should ignore the lo test
and concentrate on the "real" problem of Brett, Gabriel and myself (and
even a lot of other people out there).
Many thanks for your help!
Kind regards,
Leo
I can't reproduce this, maybe I have failed in the server stressing.
// HW
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
