|
On Sunday 06 February 2005 14:36, Joseph Mack wrote:
> You would hope that this is not the problem (ie the switch handles
> 100Mbps same way as it does 1Gbps), but it's one place to look.
And even as this was not the problem it is still nice to have gbit nics if
you have a gbit switch ;)
> The only way to find out what's happening is to look through tcpdump
> logs for the connections that have high latency and to see what's going
> on.
I've did a couple (well, a bit more) tcpdumps and went through them with
ethereal, texteditors and spreadsheets and found that; if there was a lag
in the connection that was caused by the benching machine sending out a
lot of FIN packets to the service. And after a run of 300 requests
generated with apachebench there would be 300 open connections (waiting
for an ACK) on the benching machine. They closed eventually but they
should not be open that long.
It appears I need to give chapter 17 of the howto a better look, I did use
connection tracking on my director and was dropping packets with the
following rule:
iptables --append INPUT --match state --state INVALID -j DROP
This rule dropped all the ACK's the realserver wanted to send the client
when the connection was closed, resulting in the client waiting for ACK's
and, if not receiving them for some time, send out another batch of FIN's
(which were also dropped) resulting in a very slow request... I suppose I
have to take a look at ipvs_nfct for this.
I feel stupid now...
-kees
|
