Estoy ejecutando uwsgi en modo emperador
uwsgi --emperor /path/to/vassals/ --buffer-size=32768
y obteniendo este error
invalid request block size: 21327 (max 4096)...skip
¿¿Qué hacer?? También probé -b 32768
También me encontré con el mismo problema mientras seguía un tutorial. El problema fue que configuré la opción en socket = 0.0.0.0:8000
lugar de http = 0.0.0.0:8000
.
socket
opción pensada para ser utilizada con algún enrutador de terceros (nginx por ejemplo), mientras que cuando la http
opción está configurada, uwsgi puede aceptar solicitudes HTTP entrantes y enrutarlas por sí mismo.
socket = /tmp/myapp.sock
o http = 0.0.0.0:8000
lo que sea, según sus necesidades.
La solución correcta es no cambiar al protocolo HTTP. Solo necesita aumentar el tamaño del búfer en la configuración de uWSGI.
buffer-size=32768
o en modo de línea de comandos:
-b 32768
Cita de la documentación oficial:
Por defecto, uWSGI asigna un búfer muy pequeño (4096 bytes) para los encabezados de cada solicitud. Si comienza a recibir "tamaño de bloque de solicitud no válido" en sus registros, podría significar que necesita un búfer más grande. Aumente (hasta 65535) con la opción de tamaño de búfer.
Si recibe '21573' como el tamaño de bloque de solicitud en sus registros, podría significar que está utilizando el protocolo HTTP para hablar con una instancia que habla el protocolo uwsgi. No hagas esto.
Desde aquí: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
http-socket
aquí.
uwsgi
protocolo, entonces también puede obtener el mismo error que OP
http-socket
. Cualquier otra cosa dio "502 Bad Gateway", incluso cuando se aumentó el tamaño del búfer.
Me encontré con el mismo problema al intentar ejecutarlo en nginx y seguí los documentos aquí . Es importante tener en cuenta que una vez que cambie a nginx, debe asegurarse de no intentar acceder a la aplicación en el puerto especificado por --socket param, sino más bien al puerto "escuchar" en nginx.conf. Aunque su problema se describe de manera diferente, el título coincide exactamente con el problema que tuve.
Podría arreglarlo agregando --protocol = http al uwsgi
protocol=http
a su .ini
archivo
Este error se muestra cuando el servidor uWSGI está utilizando el uwsgi
protocolo y uno intenta acceder a él a través del http
protocolo mediante curl
un navegador web directamente. Si puede, intente configurar su servidor uWSGI para usar el http
protocolo, de modo que pueda acceder a él a través del navegador web o curl.
En caso de que no pueda (o no quiera) cambiarlo, puede usar un proxy inverso (por ejemplo nginx
) frente al servidor uWSGI local o remoto, consulte https://uwsgi-docs.readthedocs.org/en/latest/Nginx .html
Si le parece demasiado trabajo, pruebe el uwsgi-tools
paquete python:
$ pip install uwsgi-tools
$ uwsgi_curl 10.0.0.1:3030
También hay un servidor proxy inverso simple uwsgi_proxy
si necesita acceder a sus aplicaciones a través del navegador web, etc. Vea una respuesta más amplia https://stackoverflow.com/a/32893520/179581
Como se señaló en otro comentario de los documentos:
Si recibe '21573' como el tamaño de bloque de solicitud en sus registros, podría significar que está utilizando el protocolo HTTP para hablar con una instancia que habla el protocolo uwsgi. No hagas esto.
Si está utilizando Nginx, esto ocurrirá si tiene esta configuración (o algo similar):
proxy_pass http://unix:/path/to/socket.sock
esto está hablando de HTTP a uWSGI (lo que lo hace gruñón). En cambio, use:
uwsgi_pass unix:/path/to/socket.sock;
el hombre tengo el mismo problema; así que lo hice ... mira usando 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: aplicación
maestro = procesos verdaderos = 33 tamaño del búfer = 32768
socket = /home/app_plataform/app_plataform.sock chmod-socket = 777 vacuum = true
2 - realice una actualización seria de rendimiento en nginx ... usuario www-data;
trabajador_procesos auto; procesos_trabajadores 4; pid /run/nginx.pid; incluir /etc/nginx/modules-enabled/*.conf;
eventos {trabajador_conecciones 4092; multi_accept on; }
http {## CONFIGURACIÓN DE ACTUALIZACIÓN
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; acceso_log desactivado;
## # Ajustes básicos ##
enviar archivo; tcp_nopush en; tcp_nodelay on; #keepalive_timeout 65; types_hash_max_size 2048; server_tokens off;
server_names_hash_bucket_size 64; # server_name_in_redirect desactivado;
incluir /etc/nginx/mime.types; default_type application / octet-stream;
## # Configuración SSL ##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dejar caer SSLv3, ref: POODLE ssl_prefer_server_ciphers en;
## # Configuración de registro ##
access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;
## # Configuración de Gzip ##
gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied
expirado sin caché no-store autenticación privada; gzip_types text / plain application / x-javascript text / xml text / css application / xml; gzip_vary on;#gzip_proxied any; #gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; #gzip_types text / plain text / css application / json application / javascript text / xml application / xml application / xml + rss text / javascript;
## # Configuraciones de host virtual ##
incluir /etc/nginx/conf.d/ .conf; incluir / etc / nginx / sites-enabled / ; }
3 - luego ... reinicie los servicios o reebot server ...
systemctl restart uwsgi y systemctl restart nginx
k
no funcionó para mí. Tenía que proporcionar el número completo. No puedo encontrar ningún puntero sobre los formatos que puedes usar aquí.