it-swarm.com.de

Fehler: Upstream vorzeitig geschlossene Verbindung beim Lesen des Antwortheaders aus Upstream [uWSGI/Django/NGINX]

Im Moment bekomme ich immer eine 502 für eine Abfrage, die meine Benutzer ausführen ... Die gibt normalerweise 872 Zeilen zurück und benötigt 2.07, um in MySQL ausgeführt zu werden. Es gibt jedoch viele Informationen zurück. (Jede Reihe enthält viele Sachen). Irgendwelche Ideen?

Ausführen des Django (tastypie Rest API), Nginx und uWSGI-Stacks.

Server-Konfiguration mit 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-Konfig

# 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
21
abisson

Dies ist wahrscheinlich kein Nginx-Konfigurationsproblem. 

Es ist fast sicher, dass das Backend tatsächlich abstürzt (oder nur die Verbindung beendet), anstatt eine missgebildete Antwort zu geben. Das heißt, die Fehlermeldung informiert Sie über das Problem, aber Sie suchen am falschen Ort, um es zu lösen.

Sie geben nicht genug Informationen, um die genaue Frage herauszufinden, aber wenn ich raten müsste:

in der Regel werden 872 Zeilen zurückgegeben und es dauert 2.07, um in MySQL zu laufen. Es gibt jedoch viele Informationen zurück.

Es ist entweder irgendwo ein Zeitlimit oder der Speicher ist knapp. 

12
Danack

Ich hatte das gleiche Problem. Was für mich behoben wurde, war das Hinzufügen meiner Domain in der einstellungen.py z.B.:

ALLOWED_HOSTS = ['.mydomain.com', '127.0.0.1', 'localhost']

Mit dem gleichen Problem meine ich, ich konnte die Seite nicht einmal laden. Nginx würde eine 502 zurückgeben, ohne Seiten zu liefern, auf denen die Anwendung abstürzen könnte.

Und das Nginx-Log enthielt: 

Error: upstream prematurely closed connection while reading response header from upstream
6
emazzotta

In Ihrem @Django-Standortblock können Sie einige Proxy-Lese- und Verbindungs-Timeout-Eigenschaften hinzufügen. z.B.

location @Django {
   proxy_read_timeout 300;
   proxy_connect_timeout 300;
   proxy_redirect off;

   # proxy header definitions
   ...
   proxy_pass http://Django;
}
1
user553620

Möglicherweise handelt es sich um ein Uwsgi-Konfigurationsproblem anstelle von Nginx. Ich habe gesehen, dass Sie uwsgi-prozesse = 2 und harakiri = 120 hatten. Haben Sie versucht, diese sowie andere Felder dort nacheinander zu ändern?

Ich hatte dasselbe Problem, aber es war nicht meine NGINX-Konfiguration. Es waren meine UWSGI-Prozesse, die Timeout-Fehler verursachten, wenn ich JSONs vom Client auf den Server stellte. Ich hatte Prozesse als 5, ich änderte es in 1 und löste das Problem. Für meine Anwendung musste ich nur einen Prozess zur Zeit ausführen. 

Hier ist die funktionierende UWSGI-Konfigurations-Autoboot-INI-Datei, die das Timeout-Problem und damit das 502-Gateway-Problem (Upstream vorzeitig geschlossen) behoben hat.

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

Ich hoffe es hilft.

0
Elia Ahadi

Manchmal kann es sich um ein Autoritätsproblem handeln. Überprüfen Sie die Berechtigung des Projektverzeichnisses.

0
季亨达