Hello!
On Tue, Jul 22, 2014 at 01:07:58PM -0400, gthb wrote:
> > - your backend app returns data in very small chunks, thus there
> > are many ngx_readv_chain() calls;
>
> That's a likely cause of high CPU usage in Nginx, right? It goes to 20% for
> this one request (without debug), the Python a
Hi,
> Trivial workaround is to use "uwsgi_buffers 8 64k" instead.
> Or you may try the following patch:
Thank you! I tried the uwsgi_buffers workaround in production, and the patch
in my reproduction setup, and indeed both seem to fix this problem; the
request runs to completion with no memory gr
Hello!
On Tue, Jul 22, 2014 at 10:51:43AM -0400, gthb wrote:
> Hi,
>
> here's a minimal configuration where I can reproduce this:
>
> error_log debug.log debug;
>
> events {
> worker_connections 1024;
> }
>
> http {
> uwsgi_buffers 64 8k;
>
> upstream nginx-test.uwsgi {
>
Hi,
here's a minimal configuration where I can reproduce this:
error_log debug.log debug;
events {
worker_connections 1024;
}
http {
uwsgi_buffers 64 8k;
upstream nginx-test.uwsgi {
server 10.0.0.7:13003;
least_conn;
}
server {
listen 8080;
That worker states indicates that the old workers are still busy.
Signaling nginx for a reload (through 'reload' service command or sending
HUP to the master, which all does the latter), *graciously* shuts old
workers down, that means leaving them finishing what they are doing without
accepting ne
Hello!
On Mon, Jul 21, 2014 at 05:44:45PM -0400, gthb wrote:
> Hi,
>
> I finally reproduced this, with debug logging enabled --- I found the
> problematic request in the error log preceding the kill signal, saying it
> was being buffered to a temporary file:
>
> 2014/07/21 11:39:39 [warn] 2
thank you
http://www.soran.edu.iq
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,251974,251974#msg-251974
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
