2010/9/16 Jean-Baptiste Quenot <[email protected]>:
> I will switch to TCP sockets, to see if the problem comes from the BSD
> socket backlog queue implementation.
>
> Then at least if the problem persists I'll be able to test your
> suggestion to print statistics of the request queue.
It's still failing with TCP sockets. I post again all facts so that
we can find a solution:
On one specific host, the 19th of september, 27 requests failed out of
955185. Here are an example entry in haproxy logs:
Sep 19 21:28:43 ws haproxy[16613]: 127.0.0.1:38847
[19/Sep/2010:21:28:13.683] fe be 0/0/0/-1/30002 504 1425 - - sH--
2/1/1/1/0 0/0 {website.com} "GET / HTTP/1.1"
Some explanations from this log entry:
* 0/0/0/-1/30000 504 indicates that the request timed out after 30
seconds, which is the haproxy timeout
* sH indicates that the timeout was reached while waiting for the
server to send valid response headers
* 6/3/3/0/0 indicates that there were 3 connections to the backend
upon request termination
Now the nginx logs:
Sep 19 21:28:43 ws nginx: 127.0.0.1 - 0 30.002 "GET / HTTP/1.1" 200 0
* again we see the 30 seconds elapsed
* we see the correct status code 200
* 0 bytes were written to the response
This is nginx 0.8.49 on Ubuntu 9.04 running on a host with 4 CPU, and
uwsgi 0.9.6 with "better handling of subprocesses" patch.
The command line is:
/usr/bin/uwsgi -l 256 -b 25000 -M -t 29 -s 127.0.0.1:25556 -A1
--pidfile /var/run/app.pid --pythonpath /app -w server -i -p 8 -d
/var/run/app.out -L
I don't believe requests are stuck in the backlog queue because I can
see the right status code in nginx logs. The problem can be
reproduced with both BSD and TCP sockets.
NOTE: the colon between host and port is replaced with a space in "ps" output
--
Jean-Baptiste Quenot
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
