uwsgi zgłasza błąd IO spowodowany przez uwsgi_response_write_body_do uszkodzoną rurę

Question

Moja aplikacja to konfiguracja uwsgi + django. Używam gevent do testowania wydajności i równoczesnego uruchamiania 1200 żądań. W tym momencie zostanie uwsgi wygeneruje błąd IO z poniższej wiadomości dziennika:

uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 260] 
IOError: write error 

Django 1.4.0
uwsgi: 01/09/13
python: 2.6
TCP Posłuchaj kolejka: 1000

Jaka jest przyczyna tego błędu zepsutej rury?

Answer 1

Ten błąd oznacza, że ​​klient zamknął połączenie, zanim uWSGI/Django wyśle ​​odpowiedź. Zwykle jest to spowodowane przekroczeniem limitu czasu w przeglądarce lub interfejsie serwera WWW.

Aby to naprawić, musisz sprawdzić, czy konfiguracja jest prawidłowa. Sprawdź, czy wszystkie części aplikacji (w tym karty baz danych) są przyjazne dla geowizji. Jeśli nie, nie osiągniesz przewagi dzięki geventom, a to może nawet doprowadzić do spadku wydajności.

Oprócz tego należy się upewnić, że serwer bazy danych jest w stanie zarządzać 1200 równoczesnymi połączeniami. Jeśli nie, może to zignorować próby połączenia.

Answer 2

Może się to zdarzyć, gdy NGINX wystosuje żądanie do uWSGI, ale uWSGI zareagowało zbyt długo, a następnie NGINX zamyka połączenie z uWSGI. Kiedy zakończy się działanie uWSGI, próbuje przekazać odpowiedź z powrotem do NGINX, ale NGINX wcześniej zamknął połączenie, a następnie uWSGI zgłosi błąd wejścia/wyjścia.

Może to oznaczać, że twój proces uWSGI trwa zbyt długo.

Aktualizacja:

tryb uWSGI Harakiri może być przydatna do automatycznego wypowiedzenia takich procesów długo maksymalnie wykorzystać, jeśli chcesz: https://uwsgi-docs.readthedocs.io/en/latest/FAQ.html#what-is-harakiri-mode możesz nie chcieć, aby to zrobić, ponieważ proces może być wykończenie jakieś długie kwerendy lub coś, co jest konieczne.

Answer 3

Teraz nie polecam tego bez twojej uwagi. Ale możesz włączyć uwsgi_ignore_client_abort na "włączony". Po włączeniu tego Nginx będzie utrzymywał przerwane połączenie otwarte, dopóki nie zwróci się uwsgi. Dlaczego nie polecam tego całkowicie, ponieważ oznacza to, że połączenie nginx będzie teraz powiązane, dopóki nie zakończy się żądanie. Ale tak naprawdę wątek uwsgi nie został przerwany, więc przerywanie wcześnie połączenia nginx naprawdę nie zyskuje zbyt wiele w mojej opinii.