Thanks Willy,
Here is the strace (constantly showing the same output very fast!) I will
try the snapshot and post my findings, let me know your thoughts on the
strace
strace -tt -p 13659
Process 13659 attached - interrupt to quit
17:56:26.908085 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.908300 gettimeofday({1363038986, 908332}, NULL) = 0
17:56:26.908378 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.908527 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.908596 gettimeofday({1363038986, 908623}, NULL) = 0
17:56:26.908657 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.908732 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.908794 gettimeofday({1363038986, 908821}, NULL) = 0
17:56:26.908855 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.908928 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.908990 gettimeofday({1363038986, 909017}, NULL) = 0
17:56:26.909051 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.909122 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.909184 gettimeofday({1363038986, 909210}, NULL) = 0
17:56:26.909244 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.909317 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.909378 gettimeofday({1363038986, 909404}, NULL) = 0
17:56:26.909443 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.909517 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
17:56:26.909579 gettimeofday({1363038986, 909605}, NULL) = 0
17:56:26.909639 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
EINVAL (Invalid argument)
17:56:26.909711 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
On Mon, Mar 11, 2013 at 5:53 PM, Willy Tarreau <[email protected]> wrote:
> Hi Saul,
>
> On Mon, Mar 11, 2013 at 05:29:10PM -0400, Saul Waizer wrote:
> > Absolutley, here is the config:
> >
> > global
> > log 127.0.0.1 local0 crit
> > pidfile /var/run/haproxy.pid
> > stats socket /var/run/haproxy.stat mode 666
> > nbproc 2
> > maxconn 65000
> > tune.maxrewrite 1024
> > tune.bufsize 32768
> > user haproxy
> > group haproxy
> > daemon
> >
> >
> > defaults
> > mode http
> > log global
> > option dontlognull
> > option httplog
> > option http-server-close
> > #option forwardfor except 127.0.0.0/8
> > option forwardfor header X-Real-IP
> > option redispatch
> > stats enable
> > stats auth change:me
> > stats uri /stav1
> > timeout connect 5000 # default 5 second time out if a backend is not
> > found
> > timeout client 300s
> > timeout server 300s
> > #timeout http-request 10s
> > #timeout queue 1m
> > #timeout http-keep-alive 10s
> > timeout check 5s
> > maxconn 65000
> > retries 3
> >
> > frontend sinatra *:5000
> > default_backend sinatra_backend
> >
> > backend sinatra_backend
> > mode http
> > balance roundrobin
> > option httpchk HEAD /ha.txt HTTP/1.0
>
> Could you please run "strace -tt -p $PID" while it's doing
> this ?
>
> Also, I suspect you're having a few servers in the backend.
> Could you please try to :
> - comment out the "timeout check"
> - comment out "nbproc 2"
>
> Neither of these should cause any issue, but you never know.
>
> Also, a number of bugs were fixed since 1.4.22 in the latest snapshot,
> waiting for more important ones to do a release (though I think I could
> do one anyway). One of them concerns the pollers where an event might
> remain present. I diagnosed that it should not cause such issues but it
> is possible that I have overlooked it. Could you then test this latest
> snapshot from there to verify if you get any difference :
>
> http://haproxy.1wt.eu/download/1.4/src/snapshot/
>
> Thanks!
> Willy
>
>
