[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uwsgi
Subject:    [uWSGI] [PATCH] fix 100% cpu usage after client disconnected
From:       roberto () unbit ! it (Roberto De Ioris)
Date:       2012-03-28 18:43:57
Message-ID: bae42e4373dda15ea1bc61ac4a5e4bc8.squirrel () manage ! unbit ! it
[Download RAW message or body]


> If the client disconnected when the application is returning a big
> response, uWSGI will produce a lot of log messages and takes 100% cpu
> usage for a period of time.
>
> This is the sample application:
>
> def application(env, start_response):
> ? ? start_response('200 OK', [('Content-Type','text/plain')])
> ? ? for i in range(1000000):
> ? ? ? ? yield 'X' * 100 + '\n'
>
> when the client disconnected, uWSGI produces a lot of log messages:
>
> send(): Broken pipe [plugins/http/http.c line 810]
> Tue Mar 27 11:26:42 2012 - write(): Connection reset by peer
> [proto/uwsgi.c line 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> SIGPIPE: writing to a closed pipe/socket/fd (probably the client
> disconnected) on request / (ip 10.5.1.238) !!!
> Tue Mar 27 11:26:42 2012 - write(): Broken pipe [proto/uwsgi.c line
> 138] during GET / (10.5.1.238)
> ...
>
> Attachment is the patch. It will check the return value of
> uwsgi_proto_uwsgi_write() and stop if necessary.
>


A similar discussion popped up some days ago (for perl), but the answer is
pretty similar:

applications should not care the server gateway. It is a requirement of
the standards. Developers write WSGI/PSGI... apps without worrying about
what happens below. This problems does not pop-up often on other projects
because error reporting is less verbose (and disconnected clients are
simply not reported most of the time).

Now, i care standards, but i care most my money :P Wasting resources on
clients that will never receive an answer is bad for money. So i would
propose to add a --close/raise/explode-on-disconnect option, that will
raise an Exception (or __DIE__ in perl, or whatever you want).

If your app can manage it, it is good, otherwise it will simply spit out
an error and goes on. For the same reason shutting up those kind of logs
could be useful too, so an option for that could be added.

By default, the behaviour must remains the one expected by the standard.

Regarding your patch, i fear that stopping the iteration of a generator in
the middle will leak memory or (in the case of ugreen/greenlet) will leave
the stack in an inconsistent state (i am not sure about that, i will make
some test)

Many thanks

-- 
Roberto De Ioris
http://unbit.it

[prev in list] [next in list] [prev in thread] [next in thread]