On Thursday 10 July 2008 02:07:35 Willy Tarreau wrote: Hi Willy,
thanks for your answer!
> Well, good and bad news. In fact I could not reproduce it. My kernel
> (2.6.25) has a bug with TCP SACKs which cause it to stop retransmitting
> after a loss... pretty sad. That was the problem I encountered when
> unplugging the cable. Disabling TCP SACKs fixed it and now I cannot
> reproduce the problem anymore. However, some code chunks look tricky and
> need deeper auditing. Also, I found a related bug which *might* have caused
> your problem but since I cannot reproduce it here, I cannot swear it's
> So could you :
> - check your kernel version, and if it's >=2.6.25, disable tcp sack :
> # echo 0 >/proc/sys/net/ipv4/tcp_sack
My kernel is 2.6.24-19 (ubuntu 8.04 server edition). I have already disabled sack but that did not help (also disabling tcp_window_scaling didn't have an effect). I also disabled tcp_frto (to solve a problem with one user who always got timeouts when dowloading large documents)
> - apply the attached patch if the problem persists after the change
I've applied the patch but deployed it only on my test-system, but there I
cannot reproduce the problem.
But I'll install the patched version on the production system in the evening - and we will see tomorrow if it solves the problem.
> - report your findings.
Yes, I'll do.
PS: I'm not even sure if this problem is caused by haproxy at all - there are
so many components in the chain, any of them could theoretically be the
internet explorer 6 -> iptables firewall -> apache 2.2.8 (with mod_ssl and mod_proxy) -> haproxy -> IIS 6
But haproxy is for me the most logical place to start debugging. Is there a possibility to log the actual size of the request body, so that I can compare it with the content length? Received on 2008/07/10 11:32
This archive was generated by hypermail 2.2.0 : 2008/07/10 11:45 CEST