Thank you for your reply, I had to stop the testing, cause it made to
much trouble.
Has someone a good idea how to produce enough load to reconstruct the
situation?
I need load to solve this problem. Everything is working fine without.
As soon as I find a way to construct some test condition I will answer
the next questions.
Thank you again for helping.
On 13.02.2012 07:59, Willy Tarreau wrote:
On Sun, Feb 12, 2012 at 02:29:12PM +0100, Sebastian Fohler wrote:
On 12.02.2012 14:24, Cyril Bonté wrote:
You said that you couldn't find anything useful in the logs.
> From the configuration you just posted, you're using the default log
format.
You should use an enhanced one, at least with "option tcplog" or
better for http : "option httplog". This is a prerequisite to find
useful information : it will help you find where time is spent (See
chapter 8.2.3 in the documentation).
Btw, talking about the configuration, your line "stat refresh s" is
wrong and ineffective (missing numbers for the refresh, which
currently disables the action, but could implies a bug in future
versions).
Thank you for that hint, I will correct that right away.
To the log option, I've already found that entry too, the only thing
with the pfsense implementation is to change that setting.
And I suspect that in the logs you'll find some "sC" flags before the
loss of the last server, indicating a timeout trying to establish a
connection. If you see some "RC" flags (which are quite rare), they
would indicate a socket or source port shortage.
Please also run a "netstat -an" on your haproxy machine in order to
check for too many FIN_WAIT2 or TIME_WAITs going to the server, just
in case...
Regards,
Willy
