Re: Rising number of connections

From: Willy Tarreau <w#1wt.eu>
Date: Sun, 5 Jul 2009 20:18:35 +0200


On Sun, Jul 05, 2009 at 05:52:20PM +0100, Peter Miller wrote:
> Well turns out it probably was an issue with not having set the timeouts. I've followed the example at http://haproxy.1wt.eu/download/1.3/examples/antidos.cfg and implemented the following in the terms of timeouts
> timeout client 60s # Client and server timeout must match the longest
> timeout server 60s # time we may wait for a response from the server.
> timeout queue 60s # Don't queue requests too long if saturated.
> timeout connect 4s # There's no reason to change this one.
> timeout http-request 5s # A complete request may never take that long.
> And the graph is much lower :-)

Nice, that was what I expected :-)

> The issue with the non-killed old processes seems to have resolved itself after I manually killed those that were left - it's possible that it was due to the described as we started off with the default haproxy version installed with debian's aptitude (which is an old version) and manually upgraded to 1.3.17.

If you had unterminated connections on the old processes, they would wait until those connections ended, which could never happen. That's why you had to kill them. BTW, you said you manually upgraded to 1.3.17. This version has a few bugs which were fixed in 1.3.18, and an important one affecting logging of long requests on some x86_64 platforms. Since 1.3.18 is a bugfix version, there is absolutely no valid reason to use 1.3.16 or 1.3.17.

> By the way for those who asked I'm implementing cacti monitoring for haproxy via snmp (on a separate server) with the following (hard-to-find) technique:
> http://haproxy.1wt.eu/download/contrib/netsnmp-perl/README

it is in the "contrib" dir in the sources you have built ;-)

Regards,
Willy Received on 2009/07/05 20:18

This archive was generated by hypermail 2.2.0 : 2009/07/05 20:30 CEST