私は現在、ユーザーが行っているクエリで常に502を取得しています...通常872行を返し、MySQLで実行するには2.07かかります。ただし、大量の情報を返しています。 (各行には多くのものが含まれています)。何か案は?
Django(tastypie Rest API)、NginxおよびuWSGIスタックを実行しています。
NGINXを使用したサーバー構成
# the upstream component nginx needs to connect to
upstream Django {
server unix:///srv/www/poka/app/poka/nginx/poka.sock; # for a file socket
}
# configuration of the server
server {
# the port your site will be served on
listen 443;
# the domain name it will serve for
server_name xxxx; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 750M; # adjust to taste
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass Django;
include /srv/www/poka/app/poka/nginx/uwsgi_params; # the uwsgi_params file you installed
}
}
UWSGI設定
# process-related settings
# master
master = true
# maximum number of worker processes
processes = 2
# the socket (use the full path to be safe
socket = /srv/www/poka/app/poka/nginx/poka.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
# clear environment on exit
vacuum = true
pidfile = /tmp/project-master.pid # create a pidfile
harakiri = 120 # respawn processes taking more than 20 seconds
max-requests = 5000 # respawn processes after serving 5000 requests
daemonize = /var/log/uwsgi/poka.log # background the process & log
log-maxsize = 10000000
#http://uwsgi-docs.readthedocs.org/en/latest/Options.html#post-buffering
post-buffering=1
logto = /var/log/uwsgi/poka.log # background the process & log
これは、nginxの設定の問題ではないでしょう。
ほぼ間違いなく、バックエンドが不正な応答を返すのではなく、実際にクラッシュしている(または単に接続を終了している)ことです。つまり、エラーメッセージは問題の内容を示していますが、間違った場所を探して解決しています。
あなたは正確な問題が何であるかを理解するために使用できるほど十分な情報を提供しませんが、私が推測しなければならなかった場合:
通常、872行を返し、MySQLで実行するには2.07かかります。ただし、大量の情報を返しています。
どこかでタイムアウトするか、メモリが不足しています。
私は同じ問題を抱えていましたが、それを修正したのは、 settings.py 例えば。:
ALLOWED_HOSTS = ['.mydomain.com', '127.0.0.1', 'localhost']
同じ問題で、ページをロードすることさえできなかったことを意味します。nginxは、アプリケーションをクラッシュさせる可能性のあるページを提供せずに502を返します。
また、nginxログには次が含まれます。
Error: upstream prematurely closed connection while reading response header from upstream
@Djangoロケーションブロックで、プロキシの読み取りと接続のタイムアウトプロパティを追加してみてください。例えば.
location @Django {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
# proxy header definitions
...
proxy_pass http://Django;
}
Nginxではなくuwsgi構成の問題である可能性があります。 uwsgiプロセス= 2およびharakiri = 120であることがわかりましたが、それらと他のフィールドを1つずつ変更してみましたか?
私は同じ問題を抱えていましたが、それはNGINX構成ではなく、クライアント側からサーバーにJSONを投稿したときにタイムアウトエラーを引き起こすUWSGIプロセスでした。プロセスは5でしたが、1に変更し、問題を解決しました。私のアプリケーションでは、一度に実行するプロセスは1つだけでした。
タイムアウトの問題、したがって502ゲートウェイの問題(アップストリームが早期に閉じられた)を解決した、動作中のUWSGI構成自動ブートiniファイルを次に示します。
autoboot.ini
#!/bin/bash
[uwsgi]
socket = /tmp/app.sock
master = true
chmod-socket = 660
module = app.wsgi
chdir = home/app
close-on-exec = true # Allow linux Shell via uWSGI
processes = 1
threads = 2
vacuum = true
die-on-term = true
それが役に立てば幸い。
権限の問題である場合があります。プロジェクトディレクトリの権限を確認してください。