it-swarm.com.de

uwsgi wirft IO Fehler, der durch eine unterbrochene Pipe verursacht wurde

Meine Anwendung ist ein uwsgi + Django-Setup. Ich verwende gevent, um Leistungstests durchzuführen und gleichzeitig 1200 Anforderungen auszuführen. An diesem Punkt gibt uwsgi einen Fehler IO = mit der folgenden Protokollmeldung aus:

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-Listenwarteschlange: 1000

Was ist die Ursache dieses Rohrbruchs? 

26
linbo

Dies kann vorkommen, wenn NGINX eine Anforderung an uWSGI gestartet hat, die Antwort jedoch zu lange dauerte. Anschließend wird die Verbindung zu uWSGI unterbrochen. Wenn uWSGI schließlich fertig ist, versucht es, die Antwort an NGINX zurückzugeben, aber NGINX hat die Verbindung früher geschlossen, so dass uWSGI einen E/A-Fehler ausgibt.

Dies könnte bedeuten, dass Ihr uWSGI-Prozess zu lange dauert.

Aktualisieren:

der Harakiri-Modus von uWSGI kann hilfreich sein, um solche langen Aufnahmeprozesse automatisch zu beenden, wenn Sie Folgendes wollen: https://uwsgi-docs.readthedocs.io/de/latest/FAQ.html#what-is-harakiri-mode Möglicherweise möchten Sie dies nicht, weil ein Prozess möglicherweise eine lange Abfrage beendet oder etwas, das erforderlich ist.

36
gitaarik

Dieser Fehler bedeutet, dass der Client die Verbindung getrennt hat, bevor uWSGI/Django die Antwort sendet. Dies wird in der Regel durch ein Timeout im Browser- oder Webserver-Frontend verursacht.

Um das Problem zu beheben, müssen Sie überprüfen, ob Ihr Setup korrekt ist. Achten Sie darauf, dass alle Teile Ihrer Anwendung (einschließlich Datenbankadapter) für Gevent geeignet sind. Wenn dies nicht der Fall ist, werden Sie mit gevent keinen Vorteil haben. Dies kann sogar zu einem Leistungsabfall führen.

Darüber hinaus müssen Sie sicherstellen, dass Ihr Datenbankserver 1200 gleichzeitige Verbindungen verwalten kann. Andernfalls werden Verbindungsversuche möglicherweise ignoriert.

2
roberto

Jetzt empfehle ich das nicht, wenn Sie Ihre Situation nicht berücksichtigen. Aber Sie könnten uwsgi_ignore_client_abort auf "on" stellen. Wenn diese Option aktiviert ist, hält nginx die abgebrochene Verbindung offen, bis uwsgi zurückkehrt. Warum ich dies nicht vollständig empfehle, liegt daran, dass eine Nginx-Verbindung jetzt gebunden ist, bis die Anforderung abgeschlossen ist. Aber der Uwsgi-Thread wurde wirklich nicht abgebrochen. Wenn Sie also die Nginx-Verbindung vorzeitig abbrechen, gewinnt das meiner Meinung nach nicht viel.

1
byoungb