uwsgi ungültige Anforderungsblockgröße

142

Ich führe uwsgi im Kaisermodus aus

uwsgi --emperor /path/to/vassals/ --buffer-size=32768

und diesen Fehler bekommen

invalid request block size: 21327 (max 4096)...skip

Was ist zu tun?? Ich habe auch versucht -b 32768

uwsgi

— Kartik Rokde
quelle

1

Die Puffergröße ist offensichtlich immer noch der Standardwert (4096). Stellen Sie sicher, dass Sie an der richtigen Instanz arbeiten. Sie können auch "-b 32k" schreiben. Stellen Sie außerdem sicher, dass diese Option (Puffergröße) in einigen Konfigurationsdateien noch nicht festgelegt ist.

— Zakinster

Es gibt keine Konfigurationsdatei. Funktioniert immer noch nicht :(

— Kartik Rokde

8

uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html Sie versuchen , zu einer uwsgi Buchse mit dem HTTP - Protokoll, zusätzlich zu diesen Optionen an den Kaiser angegeben verbinden nicht vererbt werden, es ist nur ein Prozess - Manager

— Roberto

@ zakinster Aus irgendeinem Grund hat das Wertformat mit kbei mir nicht funktioniert. Musste die volle Nummer angeben. Es können keine Zeiger auf die Formate gefunden werden, die Sie hier verwenden können.

— berühmte Garkin

207

Ich bin auch auf dasselbe Problem gestoßen, als ich einem Tutorial gefolgt bin. Das Problem war, dass ich die Option socket = 0.0.0.0:8000anstelle von gesetzt habe http = 0.0.0.0:8000. socketOption, die für die Verwendung mit httpRoutern von Drittanbietern (z. B. Nginx ) vorgesehen ist. Wenn die Option aktiviert ist, kann uwsgi eingehende HTTP-Anforderungen akzeptieren und selbst weiterleiten.

— Palasaty
quelle

5

Ich möchte dies nur kommentieren: uwsgi hat die Optionen "http", "http-socket" und "socket". Ich wollte CGI-Python-Skripte aufrufen. "Socket" war die Antwort.

— NuclearPeon

In der Nginx-Konfigurationsdatei möchten wir möglicherweise Folgendes verwenden: include / etc / nginx / uwsgi_params; uwsgi_pass django_upstream;

— Mennanov

3

Es ist nicht die richtige Lösung. Was ist, wenn wir Sockets entfernen möchten?

— Farsheed

2

@Farsheed, ich habe gerade beschrieben, warum OP diesen Fehler sieht. Wie Sie das Problem beheben können, liegt ganz bei Ihnen. Es kann socket = /tmp/myapp.sockoder http = 0.0.0.0:8000oder was auch immer sein, abhängig von Ihren Bedürfnissen.

— Palasaty

1

Obwohl diese Antwort das Problem in einigen Situationen lösen könnte, denke ich, dass die richtige Antwort im allgemeinen Fall die von @Farsheed unten bereitgestellte ist.

— Augusto Destrero

142

Die richtige Lösung besteht darin, nicht zum HTTP-Protokoll zu wechseln. Sie müssen nur die Puffergröße in den uWSGI-Einstellungen erhöhen.

buffer-size=32768

oder im Befehlszeilenmodus:

-b 32768

Zitat aus der offiziellen Dokumentation:

Standardmäßig weist uWSGI den Headern jeder Anforderung einen sehr kleinen Puffer (4096 Byte) zu. Wenn Sie in Ihren Protokollen die Meldung "Ungültige Anforderungsblockgröße" erhalten, benötigen Sie möglicherweise einen größeren Puffer. Erhöhen Sie es (bis zu 65535) mit der Option Puffergröße.

Wenn Sie in Ihren Protokollen '21573' als Anforderungsblockgröße erhalten, kann dies bedeuten, dass Sie das HTTP-Protokoll verwenden, um mit einer Instanz zu sprechen, die das uwsgi-Protokoll spricht. Tu das nicht.

Von hier aus: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

— Farsheed
quelle

1

Manchmal müssen Sie das http-Protokoll verwenden, da Unix-Sockets nur auf dem lokalen Computer verfügbar sind. Stellen Sie sich eine Situation vor, in der Sie mehrere Maschinen und einen separaten Balancer darüber haben - Sie müssen diese http-sockethier verwenden.

— Palasaty

@ Palasaty oder ein IP-Socket und ein uwsgiProtokoll, dann erhalten Sie möglicherweise auch den gleichen Fehler wie OP

— Andrei

2

@Palasaty, in jedem Fall wird das Problem behoben, wenn die Puffergröße behoben wird!

— Farsheed

Bei der Verwendung von Nginx als Reverse-Proxy musste ich verwenden http-socket. Alles andere ergab "502 Bad Gateway", selbst wenn die Puffergröße erhöht wurde.

— Hubro

Zu der zitierten Dokumentation "Wenn Sie in Ihren Protokollen '21573' als Anforderungsblockgröße erhalten, kann dies bedeuten, dass Sie das HTTP-Protokoll verwenden, um mit einer Instanz zu sprechen, die das uwsgi-Protokoll spricht. Tun Sie dies nicht." Es ist also klar, dass der Vorschlag falsch ist ... Außerdem hat der @ Kartic-Benutzer bereits versucht, die Option "-b" zu verwenden ...

— LittleEaster

14

Ich bin auf dasselbe Problem gestoßen, als ich versucht habe, es unter Nginx auszuführen, und habe die Dokumente hier befolgt . Es ist wichtig zu beachten, dass Sie nach dem Wechsel zu nginx sicherstellen müssen, dass Sie nicht versuchen, auf die App über den durch den Parameter --socket angegebenen Port zuzugreifen, sondern über den Port "listen" in nginx.conf. Obwohl Ihr Problem anders beschrieben wird, stimmt der Titel genau mit dem Problem überein, das ich hatte.

— Paulo SantAnna
quelle

Ja, ich bin auf dasselbe gestoßen. Mit anderen Worten, ich habe eine Fehlermeldung erhalten, als ich den Port lokal zusammengerollt habe, während ich erfolgreich zum 'Speicherort' meines wsgi-Reverse-Proxys navigieren konnte, wie in meiner 'nginx.conf' angegeben, da das Protokoll des wsgi-Servers aktiviert ist meine gewählte Steckdose war wsgi und nicht http

— danyamachine

14

Ich könnte das Problem beheben, indem ich --protocol = http zum uwsgi hinzufüge

— Ajamardo
quelle

2

Wie kann ich dies in der INI-Datei mit den uWSGI-Einstellungen einrichten? Meine Konfiguration funktioniert mit Ihrem Vorschlag, jedoch nur in der Befehlszeile.

— Henry Lynx

2

@ HenryLynx, fügen protocol=httpSie einfach zu Ihrer .iniDatei hinzu

— 151291

7

Dieser Fehler wird angezeigt, wenn der uWSGI-Server das uwsgiProtokoll verwendet und versucht wird, direkt über das httpProtokoll curloder den Webbrowser darauf zuzugreifen . Wenn Sie können, konfigurieren Sie Ihren uWSGI-Server für die Verwendunghttp Protokolls zu , damit Sie über einen Webbrowser oder Curl darauf zugreifen können.

Falls Sie es nicht ändern können (oder wollen), können Sie einen Reverse-Proxy (z. B. nginx) vor dem lokalen oder Remote-uWSGI-Server verwenden (siehe) https://uwsgi-docs.readthedocs.org/en/latest/Nginx) .html

Wenn es sich nach zu viel Arbeit anfühlt, probieren Sie das uwsgi-toolsPython-Paket aus:

$ pip install uwsgi-tools

$ uwsgi_curl 10.0.0.1:3030

Es gibt auch einen einfachen Reverse-Proxy-Server, uwsgi_proxywenn Sie über einen Webbrowser usw. auf Ihre Anwendung (en) zugreifen müssen. Weitere Informationen finden Sie unter https://stackoverflow.com/a/32893520/179581

— Andrei
quelle

2

Wie in einem anderen Kommentar aus den Dokumenten erwähnt:

Wenn Sie in Ihren Protokollen '21573' als Anforderungsblockgröße erhalten, kann dies bedeuten, dass Sie das HTTP-Protokoll verwenden, um mit einer Instanz zu sprechen, die das uwsgi-Protokoll spricht. Tu das nicht.

Wenn Sie Nginx verwenden, tritt dies auf, wenn Sie diese Konfiguration haben (oder etwas ähnlich Seltsames):

proxy_pass http://unix:/path/to/socket.sock

Dies spricht HTTP mit uWSGI (was es mürrisch macht). Verwenden Sie stattdessen:

uwsgi_pass unix:/path/to/socket.sock;

— Demitri
quelle

0

Mann, ich habe das gleiche Problem; Also habe ich es geschafft ... schau mit UWSGI + DJANGO + NGINX + REACT +

1 - nano /etc/uwsgi/sites/app_plataform.ini [uwsgi]

DJANGO_SETTINGS_MODULE = app_plataform.settings env = DJANGO_SETTINGS_MODULE settings.configure ()

chdir = / home / app_plataform home = / root / app_plataform module = prometheus_plataform.wsgi: application

master = true Prozesse = 33 Puffergröße = 32768

socket = /home/app_plataform/app_plataform.sock chmod-socket = 777 vakuum = true

2 - Führen Sie eine ernsthafte Leistungssteigerung für nginx ... user www-data durch.

worker_processes auto; worker_processes 4; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf;

Ereignisse {worker_connections 4092; multi_accept on; }}

http {## UPGRADE CONFIGS

client_body_buffer_size 16K; client_header_buffer_size 16k; client_max_body_size 32m; #large_client_header_buffers 2 1k;

client_body_timeout 12; client_header_timeout 12; keepalive_timeout 15; send_timeout 10; access_log off;

## # Grundeinstellungen ##

sendfile on; tcp_nopush on; tcp_nodelay on; #keepalive_timeout 65; types_hash_max_size 2048; server_tokens off;

server_names_hash_bucket_size 64; # Servername_in_redirect off;

include /etc/nginx/mime.types; default_type application / octet-stream;

## # SSL-Einstellungen ##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 löschen, ref: POODLE ssl_prefer_server_ciphers on;

## # Protokollierungseinstellungen ##

access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;

## # Gzip-Einstellungen ##

gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied
abgelaufen no-cache no-store private auth; gzip_types text / einfache anwendung / x-javascript text / xml text / css anwendung / xml; gzip_vary on;

#gzip_proxied any; #gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; #gzip_types text / einfacher text / css anwendung / json anwendung / javascript text / xml anwendung / xml anwendung / xml + rss text / javascript;

## # Virtual Host Configs ##

include /etc/nginx/conf.d/ .conf; include / etc / nginx / sites-enabled / ; }}

3 - dann ... Dienste neu starten oder Server neu starten ...

systemctl restart uwsgi & systemctl restart nginx

— Renan Moura
quelle