Nginx + uWSGIをPython=Django app。
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;
}
しかし、完了するのに約1分かかるuWSGIで長時間実行されているリクエストの場合、次のようにNginxエラーログにタイムアウトエラーが表示されます。
2013/04/22 12:35:56 [エラー] 2709#0:* 1アップストリームがタイムアウトしました(110:接続がタイムアウトしました)。アップストリームから応答ヘッダーを読み取り中、クライアント:xx.xx.xx.xx、サーバー:、リクエスト:「GET/entity/datasenders/HTTP/1.1」、アップストリーム:「uwsgi://127.0.0.1:9001」、ホスト:「xxx.xx.xx.x」
ヘッダーのタイムアウトとuWSGIの送信/読み取りタイムアウトを5分に設定しましたが、これを克服するために何ができるか教えてください。
問題を解決する構成は次のとおりです。
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:9001;
uwsgi_read_timeout 300;
index index.html index.htm;
}
質問の上記の構成が機能しなかった理由は、残念ながら、マシンの複数のパスにnginx.conf
ファイル。間違ったパスでconfを操作していました。
Nginxが実行から設定を取得しているパスを正しく把握するには:
nginx -V # V is caps
これには--conf-path=[]
これは、設定の取得元を正確に示します。
最近、上記のnginx -V
正しい情報を提供しません。他の人が便利だと思う場合に備えて、上記の説明は残しておきます。
「uwsgi_read_timeout」の回答に加えて、nginx uwsgiキャッシュディレクトリの所有権が正しいことも確認する必要があります。所有権は、実行中のnginxプロセスと同じユーザーに設定する必要があります...私の場合、これを行う必要がありました
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
これらのファイルは同じユーザーが所有していますか?そうでない場合は、nginxをシャットダウンしてすべてのキャッシュファイルを削除し、適切な所有者が/ var/cache/nginx/uwsgi_tempにあることを確認して再起動します。たぶん、あなたは単に再帰的なクラウンを行うこともできます、私はこのアプローチをテストしませんでした。
# store the user
THEUSER=$(grep '^user' /etc/nginx/nginx.conf | sed 's/.* //; s/;.*//' )
/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
chown -R $THEUSER:$THEGROUP /var/cache/nginx/uwsgi_temp/
# not sure if you have to restart nginx here...