One upstream connection blocks another upstream connection
Lars Jeppesen
jeppesen.lars at gmail.com
Thu Mar 15 08:41:49 UTC 2018
> Mix of different times in logs suggests that workers are blocked for a
long time doing something
> (and hence the time in some worker process are not updated for a long
time).
> Reasons can be different, and more information/logs are needed to say
anything for sure. In this particular case my best guess is that your
backend server is much faster than the disk you use for proxy_temp_path,
> and so nginx loops buffering a response to disk for a long time. For
example, the response in *189 already buffered about 600M, and there is no
indication in the log lines quoted that it stopped reading from the
upstream somewhere.
> At the same time the process thinks current time is 13:53:32, which is 21
seconds behind 13:53:53 as logged by pid 18729 at the same time.
>
> An obvious workaround would be to disable or limit disk buffering,
"proxy_max_temp_file_size 0;". Additionally, using larger memory buffers
(proxy_buffer_size, proxy_buffers) might help to avoid such monopolization
of a worker process.
>
> See also https://trac.nginx.org/nginx/ticket/1431 for a detailed
explanation of a similar problem as observed with websocket proxying.
>
> Maxim Dounin
This seemed to be the problem. The upstream was delivering data too fast
compared to writing the temp file. I tried to increase the buffer but that
didn't help. I disabled the temp file completely at the problem
disappeared. I no longer see this monopolization of the worker process.
Thanks for the help Maxim.
Best regards
Lars
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180315/2ab8c570/attachment.html>
More information about the nginx
mailing list