2016-03-22 17 views
9

Moja aplikacja używa nginx, z uWSGI po stronie serwera. Kiedy zrobić dużą prośbę (z czasem reakcji> 4S), zostanie wyświetlone następujące okno:uWSGI podnosi OSError: błąd zapisu podczas dużego żądania

SIGPIPE: writing to a closed pipe/socket/fd (probably the client 
    disconnected) on request _URL_ (ip XX.XX.XX.XX) !!! 

uwsgi_response_writev_headers_and_body_do(): Broken pipe 
    [core/writer.c line 287] during GET _URL_ (XX.XX.XX.XX) 

OSError: write error 

Wydaje się, że uWSGI próbuje pisać w strumieniu ale strumień ten został już zamknięty. Kiedy sprawdzić dziennik nginx (error.log):

upstream prematurely closed connection while reading response 
    header from upstream ... 

Oczywiście, mój klient (klient REST lub przeglądarki) otrzyma błąd 502.

Zawsze otrzymuję ten błąd po ~ 4s.

Jednak nie wiem, jak zapobiec temu problemowi. Próbowałem ustawić kilka parametrów w moim pliku config nginx:

location my_api_url { 
    [...] 
    uwsgi_buffer_size 32k; 
    uwsgi_buffers 8 32k; 
    uwsgi_busy_buffers_size 32k; 

    uwsgi_read_timeout 300; 
    uwsgi_send_timeout 300; 

    uwsgi_connect_timeout 60; 
} 

Ale problem jest nadal tutaj. Próbowałem też ustawić te parametry w pliku konfiguracyjnym uWSGI (wsgi.ini):

buffer-size=8192 
ignore-sigpipe=true 
ignore-write-errors=true 

Przed spróbować zoptymalizować czas odpowiedzi, mam nadzieję, że ten problem ma rozwiązanie. Nie znajduję takiego, który działa w innym poście. Pracuję z dużą ilością danych, więc mój czas odpowiedzi, w przypadku niektórych przypadków, wynosi od 4 do 10 sekund.

Mam nadzieję, że mi pomożesz:

Dziękuję bardzo z góry.

+0

Czy jesteś NGINX za proxy lub coś? Zazwyczaj błąd zapisu występuje, gdy klient zamknął połączenie z wyprzedzeniem. –

Odpowiedz

5

Może się zdarzyć, że podczas przesyłania rzeczy używasz kodowania fragmentarycznego. Istnieje opcja uWSGI --chunked-input-timeout, że domyślnie wynosi 4 sekundy (to defaults do wartości --socket-timeout, która wynosi 4 sekundy).

Chociaż problem teoretycznie może leżeć gdzie indziej, sugeruję wypróbowanie wymienionych wyżej opcji. Plus, denerwujące wyjątki są powodem dlaczego mam

ignore-sigpipe=true 
ignore-write-errors=true 
disable-write-exception=true 

w moim uWSGI config (zauważ, że ja daje 3 opcje, a nie 2): ignore-sigpipe sprawia nie uWSGI pokazać błędy SIGPIPE; ignore-write-errors powoduje, że nie wyświetlają się błędy z numerem , np. uwsgi_response_writev_headers_and_body_do; disable-write-exception zapobiega generacji przy zapisach.

+0

Dzięki! Naprawdę pomocna odpowiedź! – JulCh