2013-04-22 13 views
30

Ho Nginx + uWSGI per l'app Python Django.Timeout Nginx quando uWSGI impiega molto tempo per elaborare la richiesta

Ho il seguente nel mio nginx.conf:

location/{ 
    include uwsgi_params; 
    uwsgi_pass 127.0.0.1:9001; 
    uwsgi_read_timeout 1800; 
    uwsgi_send_timeout 300; 
    client_header_timeout 300; 
    proxy_read_timeout 300; 
    index index.html index.htm; 
} 

ma per le richieste a lungo in esecuzione sul uWSGI che dura circa 1 minuto per completare ottengo un errore di timeout in Nginx log degli errori, come di seguito:

2013/04/22 12:35:56 [errore] 2709 # 0: * 1 upstream scaduto (110: Connessione scaduta) durante la lettura dell'intestazione della risposta da upstream, client: xx.xx.xx.xx, server:, richiesta: "GET/entity/datasenders/HTTP/1.1", a monte: "uwsgi: //127.0.0.1: 9001", host: "xxx.xx.xx.x"

Ho già impostato il timeout dell'header e l'uWSGI invia/legge i timeout a 5 minuti, qualcuno può dirmi per favore cosa posso fare per superare questo?

risposta

49

La configurazione che risolve il problema è:

location/{ 
    include uwsgi_params; 
    uwsgi_pass 127.0.0.1:9001; 
    uwsgi_read_timeout 300; 
    index index.html index.htm; 
} 

La ragione per la configurazione di cui sopra in questione non ha funzionato per noi, perché, purtroppo, nelle nostre macchine più percorsi avevano nginx.conf file. Stavamo lavorando con il conf sulla strada sbagliata.

Per capire correttamente quale percorso vostra nginx è in ripresa la configurazione da corsa:

nginx -V # V is caps 

questo avrà un --conf-path=[] che vi dirà esattamente dal punto in cui si è in ripresa la configurazione da.

Recentemente ho trovato il precedente nginx -V per non dare le informazioni giuste. Lascerò quanto sopra nel caso in cui gli altri lo trovino utile.

+1

che cosa è quel numero che rappresenta? secondi? e sarà un problema se lo avessimo impostato su un grande numero come 2000? – senaps

0

Oltre alla risposta "uwsgi_read_timeout", è necessario verificare che la proprietà sia corretta per la directory della cache uwsgi nginx. La proprietà deve essere impostato allo stesso utente come il processo in esecuzione nginx ... Nel mio caso ho dovuto fare questo

grep '^user' /etc/nginx/nginx.conf 
ls -lah /var/cache/nginx/uwsgi_temp 
for f in $(find /var/cache/nginx/uwsgi_temp); do ls -lah $f; done 

Sono questi file di proprietà di uno stesso utente? In caso contrario, è possibile chiudere nginx e rimuovere tutti i file della cache, assicurarsi che il proprietario sia su/var/cache/nginx/uwsgi_temp e riavviare. Forse potresti anche solo fare un chown ricorsivo, non ho provato questo approccio.

# store the user 
THEUSER=$(grep '^user' /etc/nginx/nginx.conf | sed 's/.* //; s/;.*//') 

di cache Rimuovere e riavviare approccio

/etc/init.d/nginx stop 
rm -rf /var/cache/nginx/uwsgi_temp/* 
chown $THEUSER:$THEUSER /var/cache/nginx/uwsgi_temp 
/etc/init.d/nginx start 

ricorsivo approccio chown

chown -R $THEUSER:$THEGROUP /var/cache/nginx/uwsgi_temp/ 
# not sure if you have to restart nginx here... 
Problemi correlati