On Mon, Aug 16, 2010 at 09:30:28PM +0200, Alexander Staubo wrote: > On Mon, Aug 16, 2010 at 9:06 PM, Willy Tarreau <[email protected]> wrote: > >> We have now turned the option off temporarily to see if that helps; > >> it's only been half an hour, but no problems yet, so I'm optimistic. I > >> will let you know when we have confirmed that the problem has > >> definitely been solved. > > > > That would be good. > > Everything still looks good with the modified setting. We have enabled > it permanently now. > > Googling a bit, I see that a lot of people have turned on > net.ipv4.tcp_tw_recycle in conjunction with HAProxy:
It's in part my fault, I had it in my early tuning scripts, at times it did not cause trouble. Those were the times when I was happy to see it reach 1500 connections per second ;-) > > > http://www.google.no/search?sourceid=chrome&ie=UTF-8&q=haproxy+net.ipv4.tcp_tw_recycle > > In fact, there's even a guy named Willy who talks about enabling it ;-) > > http://haproxy.1wt.eu/download/1.3/doc/tcp-splicing.txt Yes indeed :-/ > Might I suggest adding a new section to the HAProxy documentation that > deals with the various OS tuning options? That would be a good place > to place a note that discourages the use of net.ipv4.tcp_tw_recycle. The doc should be considerably improved, but yes this can be added. > >> Apparently there's a safer option that serves an almost identical > >> purpose, net.ipv4.tcp_tw_reuse. We are going to try enabling that one > >> later. > > > > That's the one I'm using ;-) > > Excellent. Often you also have to use tcp_timestamps=1 with this, for instance if you're passing through some NAT firewalls or some equipments that randomize TCP sequence numbers. Enabling timestamps makes use of the PAWS TCP extension which extends sequence numbers with timestamps, leveraging any ambiguity that could result from an early source port reuse. Regards, Willy
