2015-07-20 16 views
5

Wciąż otrzymuję ten błąd na relacje z Nginx:uwsgi_response_write_body_do() timeout - Ale nie uwsgi_read_timeout pomagając (x-post)

uwsgi_response_write_body_do() TIMEOUT !!! 
IOError: write error 

To zazwyczaj działa bez zarzutu. Dzieje się tak tylko wtedy, gdy testuję z 50+ równoczesnymi połączeniami, trafiając w metodę, która wysyła 200 MB danych.

Szukałam całego ale widzę radzą, aby zwiększyć uwsgi_read_timeout :-(

(Poprosiłem na stronie uwsgi github, ale myślę, że ponieważ nie jest prawdopodobnie błąd to lepiej zapytać tutaj)

Oto jak ja uruchomienie uwsgi:

flask/bin/uwsgi -s 127.0.0.1:9001 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_01.log 
flask/bin/uwsgi -s 127.0.0.1:9002 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_02.log 
flask/bin/uwsgi -s 127.0.0.1:9003 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_03.log 
flask/bin/uwsgi -s 127.0.0.1:9004 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_04.log 
flask/bin/uwsgi -s 127.0.0.1:9005 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_05.log 
flask/bin/uwsgi -s 127.0.0.1:9006 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_06.log 
flask/bin/uwsgi -s 127.0.0.1:9007 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_07.log 
flask/bin/uwsgi -s 127.0.0.1:9008 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_08.log 
flask/bin/uwsgi -s 127.0.0.1:9009 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_09.log 
flask/bin/uwsgi -s 127.0.0.1:9010 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_10.log 
flask/bin/uwsgi -s 127.0.0.1:9011 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_11.log 
flask/bin/uwsgi -s 127.0.0.1:9012 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_12.log 
flask/bin/uwsgi -s 127.0.0.1:9013 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_13.log 
flask/bin/uwsgi -s 127.0.0.1:9014 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_14.log 
flask/bin/uwsgi -s 127.0.0.1:9015 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_15.log 
flask/bin/uwsgi -s 127.0.0.1:9016 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_16.log 
flask/bin/uwsgi -s 127.0.0.1:9017 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_17.log 
flask/bin/uwsgi -s 127.0.0.1:9018 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_18.log 
flask/bin/uwsgi -s 127.0.0.1:9019 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_19.log 
flask/bin/uwsgi -s 127.0.0.1:9020 --need-app --wsgi-file app.py --processes 1 --callable app --daemonize /opt/logs/KVAutobus-uwsgi_20.log 

Oto /etc/nginx/nginx.conf:

user nginx; 
worker_processes 10; 

error_log /var/log/nginx/error.log warn; 
pid  /var/run/nginx.pid; 

events { 
    worker_connections 2024; 
} 
http { 
    include /etc/nginx/mime.types; 
    default_type application/octet-stream; 
    log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 
         '$status $body_bytes_sent "$http_referer" ' 
         '"$http_user_agent" "$http_x_forwarded_for"'; 

    access_log /var/log/nginx/access.log main; 
    sendfile  on; 
    #tcp_nopush  on; 
    keepalive_timeout 20; 
    gzip on; 
    include /etc/nginx/conf.d/*.conf; 
} 

Oto /etc/nginx/conf.d/default.conf:

upstream internal { 
    least_conn; 
    server 127.0.0.1:9001; 
    server 127.0.0.1:9002; 
    server 127.0.0.1:9003; 
    server 127.0.0.1:9004; 
    server 127.0.0.1:9005; 
    server 127.0.0.1:9006; 
    server 127.0.0.1:9007; 
    server 127.0.0.1:9008; 
    server 127.0.0.1:9009; 
    server 127.0.0.1:9010; 
    server 127.0.0.1:9011; 
    server 127.0.0.1:9012; 
    server 127.0.0.1:9013; 
    server 127.0.0.1:9014; 
    server 127.0.0.1:9015; 
    server 127.0.0.1:9016; 
    server 127.0.0.1:9017; 
    server 127.0.0.1:9018; 
    server 127.0.0.1:9019; 
    server 127.0.0.1:9020; 
} 

server { 

    listen 9000 default_server; 
    server_name _; 
    proxy_max_temp_file_size 4024m; 
    #access_log logs/host.access.log main; 
    location/{ 
    uwsgi_pass   internal; 

    uwsgi_param Host     $host; 
    uwsgi_param X-Real-IP   $remote_addr; 
    uwsgi_param X-Forwarded-For  $proxy_add_x_forwarded_for; 
    uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto; 

    #not sure which timeout parameter I need 
    proxy_read_timeout 600; 
    proxy_connect_timeout 1d; 
    proxy_max_temp_file_size 5024m; 
    proxy_send_timeout 600; 
    uwsgi_read_timeout 600; 
    uwsgi_send_timeout 600; 
    include uwsgi_params; 
    } 
} 
+0

udało Ci się rozwiązać problem? Mam podobny problem. – adamczi

Odpowiedz

0

Wystarczy użyć dyrektywy:

uwsgi_max_temp_file_size 0; 

lub

uwsgi_buffering off; 

wyłączyć bufor w Nginx.

Myślę, że prędkość transmisji z nginx do klienta jest znacznie wolniejsza od prędkości uwsgi do nginx. A bufor nginx jest pełny, więc uwsgi czekają dużo czasu, zanim pojawi się miejsce na Nginx na otrzymywanie nowych danych, co spowoduje, że upłynie limit czasu zapisu.

Możesz przeczytać moją analizę na temat tego problemu w moim blogu: http://kmiku7.github.io/2018/02/02/Solve-the-problem-of-uwsgi-uwsgi-response-write-body-do-TIMEOUT-error/