> I activated $request_time in nginx logs and indeed I'm reaching the > haproxy timeout (30s), whereas harakiri is set to a lower value (29s), > but no worker is killed. I allocated two times more workers, and the > problem is still present.
Remember that harakiri starts when the worker accept() the connection. If the connection is accepted after "28.9 secs" haproxy (or nginx) will be faster than harakiri :) I have started investigating a way to read the socket backlog status. Sadly there is no a standard/approved way. For TCP sockets on Linux and FreeBSD we can use getsockopt() with TCP_INFO command: http://linux.die.net/man/7/tcp I am testing it, and it can print the requests currently enqueued. This is amazing as it will allow you to know when uWSGI is not able to respond fast. Example: you have found that haproxy returned empty response at 17:17:17 of the 14 of semptember. You go to the uWSGI logs and look if in those range there is a queue overload. You see a value of 20/64 enqueued connections. This is the conformation of "too blocking" than you add more workers and recheck. Example2: You often get connection refused as the socket backlog is full and all the workers are busy. Enabling socket tcp_info, you can control in realt-time how big the socket backlog should be. This functionality can be useful even for load statistics, as having (even) 1 connection enqueued is a sign of all the workers busy. I have not found a way to gather the same information on UNIX socket (in the linux kernel sources for af_unix there are no code to export those values), so this function will be TCP (and Linux/FreeBSD) specific. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
