Python uwsgi 抛出 uwsgi_response_write_body_do 断管引起的 IO 错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17504435/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
uwsgi throws IO error caused by uwsgi_response_write_body_do broken pipe
提问by linbo
My application is a uwsgi+django setup. I use gevent to do performance testing and run 1200 requests concurrently. At this point, uwsgi will throw an IO error with the following log message:
我的应用程序是 uwsgi+django 设置。我使用 gevent 进行性能测试并同时运行 1200 个请求。此时，uwsgi 将抛出 IO 错误并显示以下日志消息：
uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 260]
IOError: write error
Django 1.4.0
uwsgi: 1.9.13
python: 2.6
TCP Listen queue: 1000
Django 1.4.0
uwsgi：1.9.13
python：2.6
TCP 监听队列：1000
What is the cause of this broken pipe error?
这个断管错误的原因是什么？
回答by roberto
This error means that the client has closed the connection before uWSGI/Django sends the response. It is generally caused by a timeout in the browser or web server frontend.
这个错误意味着客户端在 uWSGI/Django 发送响应之前已经关闭了连接。它通常是由浏览器或 Web 服务器前端的超时引起的。
To fix it, you need to verify that your setup is correct. Look to see that all of your application's parts (including database adapters) are gevent-friendly. If they're not, you will get no advantage with gevent, and this could even lead to a decrease in performance.
要修复它，您需要验证您的设置是否正确。看看你的应用程序的所有部分（包括数据库适配器）都是 gevent 友好的。如果不是，您将无法使用 gevent，这甚至可能导致性能下降。
In addition to this, you need to make sure that your database server is able to manage 1200 concurrent connections. If not, it may be ignoring connection attempts.
除此之外，您需要确保您的数据库服务器能够管理 1200 个并发连接。如果没有，它可能会忽略连接尝试。
回答by gitaarik
This can happen when NGINX started a request to uWSGI but uWSGI took too long to respond, then NGINX closes the connection to uWSGI. When uWSGI finally finishes, it tries to give it's response back to NGINX, but NGINX closed the connection earlier, so then uWSGI throws an I/O error.
这可能发生在 NGINX 开始向 uWSGI 发出请求但 uWSGI 响应时间过长，然后 NGINX 关闭与 uWSGI 的连接时。当 uWSGI 最终完成时，它试图将它的响应返回给 NGINX，但 NGINX 提前关闭了连接，因此 uWSGI 抛出一个 I/O 错误。
So this could mean that your uWSGI process is taking too long.
所以这可能意味着你的 uWSGI 过程花费的时间太长。
Update:
更新：
uWSGI's Harakiri mode could be useful to automatically terminate such long taking processes if you want to: https://uwsgi-docs.readthedocs.io/en/latest/FAQ.html#what-is-harakiri-modeYou might not want to do this because a process might be finishing some long query or something which is necessary.
如果您愿意，uWSGI 的 Harakiri 模式可能有助于自动终止如此耗时的进程：https://uwsgi-docs.readthedocs.io/en/latest/FAQ.html#what-is-harakiri-mode 您可能不想这样做是因为一个进程可能正在完成一些长查询或一些必要的事情。
回答by byoungb
Now I am not recommending this without you considering your situation. But you could turn uwsgi_ignore_client_abortto "on". With this turned on nginx will keep the aborted connection open until uwsgi returns. Why I don't recommend this completely is because this means an nginx connection will now be tied up until the request finishes. But really the uwsgi thread wasn't being aborted, so aborting the nginx connection early isn't really gaining you much in my opinion.
现在我不会在没有你考虑你的情况的情况下推荐这个。但是您可以将uwsgi_ignore_client_abort 设置为“打开”。启用此功能后，nginx 将保持中止的连接打开，直到 uwsgi 返回。为什么我不完全推荐这样做是因为这意味着 nginx 连接现在将被绑定，直到请求完成。但实际上 uwsgi 线程并没有被中止，所以在我看来，提前中止 nginx 连接并没有真正让你受益。
