Hello,
I have a setup where I need to restart my (rails) fastcgi processes
rather
often (about hourly). I think the processes are being shutdown cleanly
(ie:
a flag is set by a signal, and when the request completes they exit 0),
still, if the load is high nginx starts reporting error log lines like:
2009/12/21 18:42:20 [error] 25219#0: *277 upstream prematurely closed
connection while reading response header from upstream, client:
10.51.248.185, server: my.server.com, request: “GET
/project/xeditor/visual_edit/1 HTTP/1.0”, upstream:
“fastcgi://unix:/tmp/xmanager_fcgi.sock:”, host: “dmzxmweb05:8080”
and starts spitting out 502 errors. The problem gets worse if more
fastcgi
processes are started, but sometimes it does it even with 5 only (it’s
an 8
cpu box).
I cannot totally rule out the possibility that my processes are shutting
down less cleanly that they should (maybe a race condition?), but in
testing
they seem to be shutting down ok, and so they should have finished
sending
the response. Also, may this actually be caused by nginx “losing”
connection
with the socket - receiving 0 bytes, rather than actually getting a
partial
response?
Is there some nginx config param I can tweak to try in order to get rid
of
those 502’s ?? or either any suggestion on somewhere else to look for
problems and solutions?
Regards
Luca de Marinis
Interact S.p.A.
I cannot totally rule out the possibility that my processes are shutting
down less cleanly that they should (maybe a race condition?), but in
testing
they seem to be shutting down ok, and so they should have finished sending
the response. Also, may this actually be caused by nginx “losing”
connection
with the socket - receiving 0 bytes, rather than actually getting a
partial
response?
Yes, this may (and probably is) the cause.
Is there some nginx config param I can tweak to try in order to get rid of
those 502’s ?? or either any suggestion on somewhere else to look for
problems and solutions?
After such error nginx tries another backend in upstream {}, so this
shouldn’t be an issue unless you restart all backends at the same time.
Best regards,
Piotr S. < [email protected] >
On Tue, Dec 22, 2009 at 4:29 PM, Piotr S.
[email protected]wrote:
Is there some nginx config param I can tweak to try in order to get rid of
those 502’s ?? or either any suggestion on somewhere else to look for
problems and solutions?
After such error nginx tries another backend in upstream {}, so this
shouldn’t be an issue unless you restart all backends at the same time.
Currently I have a single backend with n processes listening on the same
unix socket, in order to use multiple ones I may consider switching to
something like mongrel_cluster, but I fear that they would probably
still be
terminated at the same time.
I’m going to give it a try anyway, thanks!