Hello list,
for a Flask based uWSGI application behind nginx (python 3.6, FreeBSD)
I'm seeing following errors logged:
"uwsgi_response_write_body_do() TIMEOUT !!!"
sometimes followed by:
"OSError: write error"
sometimes only the OSError is logged by uwsgi.
Those error entries are logged/correlated for the http requests failing
with a 502, and nginx logging the following
"kevent() reported that connect() failed (54: Connection reset by peer)
while connecting to upstream, client: ..."
The requests are logged to last 6-8 seconds for $upstream_response_time
that we add to access logs among other non-standard things, which is
less than default uwsgi_*_timeout of 60s. This means that the backend
threw the OSError within 6-8 seconds of the request. And also,
uwsgi_*_timeouts are on the nginx side which is not the one reporting a
timeout.
Googling for this I found a few posts, among them this:
https://stackoverflow.com/questions/31522656/uwsgi-response-write-body-do-timeout-but-uwsgi-read-timeout-not-helping-x-p
that essentially recommends disabling uwsgi buffering.
Which got me thinking that I might be having a buffering configuration
problem. nginx has the following related configs:
* uwsgi_buffer_size size;
* uwsgi_buffering on | off;
* uwsgi_buffers number size;
* uwsgi_busy_buffers_size size;
So far all of them were at their default values.
But I can't figure out:
* What exactly is uwsgi_busy_buffers_size about
* What is the relation between number of buffers in uwsgi_buffers and
concurrency? What happens if I have more concurrent requests than
buffers? Should I raise count or size or both? Is this even related....
I have now done contrary to that StackOverflow post and instead
increased both the number and size for uwsgi_buffers; assuming this
might be a concurrency issue, from default 8 4k to 32 128k. So far so
good, I no longer see these errors, but I don't accept a fix that I
don't understand why it's a fix.
I see there's a number of timeout related uwsgi config options, but I
have no idea which one might be relevant.
Any help is appreciated.
--
Vlad K.
_______________________________________________
uWSGI mailing list
uWSGI@lists.unbit.it
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
