アップストリームとして別個のuwsgi/djangoサーバーを使用するロードバランサー(least_conn)としてNginxでサイトをセットアップしました。これは通常、約5つのuwsgi/djangoサーバーのプールですが、私はそれが悪いサーバーではないことを確認するために1つに制限しました。Nginxリバースプロキシーuwsgi django断続的502
「通常の」ユーザーの動作では、すべて正常に動作しているようです。 私の問題は、迅速で連続したリクエストが断続的に502エラーを生成することです。すべての記事のリストを含む管理者ページを開いて、これをいくつかの試行で再作成することができます。新しいタブでリンクの束を開くと、約10分の1が失敗し、502エラーが発生します。
もう1つの好奇心、502sは起こると非常に迅速に起こります。たとえば、502が表示されているときは、タブが開くほど瞬時に表示されます。どこでエラーが返ってくる前に、nginxのフロントエンドがちょっと待ってくれると期待しています。
私は、nginxロードバランサとuwsgiを直接プロキシするためにuwsgi_passを使用しています。私は、バッファを増やさなければならないという数多くの他の記事を読みました。私はuwsgi_buffers_size 16kを設定しようとしました。 uwsgi_buffers 4 16k;しかし彼らは違いをもたらさなかった。
NginxとUwsgiの両方からのエラーログには、502についての何も表示されません。しかし、Googleのウェブマスターツールはそれに気づいています。
関連nginx.confの設定:
worker_processes auto;
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
events {
multi_accept on;
use epoll;
worker_connections 1024;
}
http {
include 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 off;
sendfile on;
tcp_nopush on;
#Timeouts
keepalive_timeout 65;
send_timeout 60;
client_body_timeout 12;
client_header_timeout 12;
upstream backend {
least_conn;
server ipaddress:22882;
}
server {
listen 27313;
server_name exampledomain.com;
access_log off;
port_in_redirect off;
uwsgi_next_upstream error;
location/{
uwsgi_read_timeout 300;
uwsgi_send_timeout 150;
uwsgi_connect_timeout 300;
uwsgi_buffer_size 16k;
uwsgi_buffers 4 16k;
uwsgi_pass backend;
}
Uwsgiは、これらのパラメータで開始:
--socket :22882
--master
--workers 5
--threads 2
--max-requests 1500
--wsgi-file ~/django_prod/wsgi.py
--pidfile ~/django_prod/nginx/log/uwsgi.pid
--daemonize ~/django_prod/nginx/log/uwsgi.log
--python-path ~/django_prod
--python-path ~/django_prod/lib/
--env DJANGO_SETTINGS_MODULE=myproject.settings
--vacuum
エラー502は504とは異なります。「ゲートウェイタイムアウト」ではないため「ゲートウェイエラー」であるため、本当の理由はdjango側です。 作業者の制限を超えた場合、djangoはその後のrewuestsで502エラーをスローしますが、私はdjangoが確実に分かります。 –
私は、ページ502s、UWSGIのログ内の対応するエントリが他の作業要求と同様に正常に表示されることを確認しています。 私は、この記事が、時間と、これが通常はアクセスされない非常に古い記事であるという事実に基づいて、502でエラーを起こしたページであることを知っています。 [pid:3226 | app:0 | req:565/2827] 127.0.0.1(688/1628バイト)[Tue Oct 25 10:55:02 2016] GET/admin/news/news/149/?_changelist_filters = p%3D218 => 92バイト(HTTP/1.0 200)で13862バイト、307バイトに6つのヘッダー(コア0のスイッチ1つ) – finnthehuman