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! > > 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). This issue is probably caused by server delivering as miscalculated SYN/ACK (the acked number is miscalculated, see my second mail). 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
