Hi,
On Fri, Mar 28, 2008 at 03:39:54PM +0100, Alexander Staubo wrote:
On 3/14/08, Grzegorz Nosek
<grze...@public.gmane.org> wrote:
If it doesn't kill your I/O, it might be useful (as an insight into WTF
the fair balancer is choosing). I think that the most useful would be
capturing debug_http logs (only those with [upstream_fair] should be
enough), but that generates a truly massive amount of data.
Running strace -e connect on this process yields an infinite sequence
of the following two lines:
connect(3, {sa_family=AF_INET, sin_port=htons(11003),
sin_addr=inet_addr("...")}, 16) = -1 EINPROGRESS (Operation now in
progress)
connect(4, {sa_family=AF_INET, sin_port=htons(11003),
sin_addr=inet_addr("...")}, 16) = -1 EINPROGRESS (Operation now in
progress)
where the address being connected to is one of the back ends. I also
ran a full strace, and I can send you the output privately if you
like.
Yes, please do.
I have not tried the latest snapshot yet. We are still running the one
from February 12th or so.
Please upgrade then, hopefully the problem is fixed now (at least I
haven't heard of any new reports).
17 messages in ru.sysoev.nginxRe: Nginx + fair load balancer patch ...
