Re: strange logging line/statistics weirdness - plus 'timeout queue' weirdness?

Hi Jeffrey,

On Wed, Aug 27, 2008 at 12:44:07PM +0800, Jeffrey 'jf' Lim wrote:
> hi folks, I've got a situation where I have maxconn set on a frontend,
> and it seems that when this happens and the maxconn is hit, a
> connection can stay stuck indefinitely in some queue until a
> connection slot is freed up? Initially, I was thinking that perhaps
> the 'timeout queue' would cover this, but apparently not. I've got
> 'timeout queue 5s' in the defaults section, but my connection will
> stay stuck forever, until a connection slot is freed up.
>
> In addition to 'timeout queue' not being effective (yes, I know
> 'timeout queue' is not applicable for a frontend, but then... should
> we be able to set a timeout for this still?)

There is no queue in frontends. They simply stop accepting requests when their maxconn is reached. However, it is possible that you have been waiting in the queue on the backend, but the log should reflect that.

> The strange log line I see (questionable value is Tt - since I
> obviously spent a minute and a half waiting for a reply)
>
> (extra cruft cut) [27/Aug/2008:12:30:53.081] front-xxx
> back-xxx/server1 0/0/0/0/17 200 362 - - --VN 0/0/0/0/0 0/0 "GET /
> HTTP/1.1"
>
> Is this correct? Tt = 0?

The total time here is 17 ms and the log indicate that you spent no time in the queue nor anywhere BTW (everything ran instantly). While it's possible, it seems very unlikely, especially considering the time you waited. What version is this ? Wouldn't this be one before 1.3.14.6 or 1.3.15.2 ? In earlier versions, the queue management was buggy but IMHO it would not end up doing nasty things like this.

Something you can check is the difference in time between what syslog days and what haproxy says. syslogd indicates the time its received the log, which generally corresponds to the end of session. haproxy logs the time it received the connection. Most often, the difference between both is approximately equal to the total time (more or less rounding errors due to syslog having a granularity of one second).

Regards,
Willy Received on 2008/09/02 22:23