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