Uruchamiam uwsgi w trybie cesarza

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

i otrzymuję ten błąd

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

Co robić?? Próbowałem też -b 32768

Również natknąłem się na ten sam problem podczas korzystania z samouczka. Problem polegał na tym, że socket = 0.0.0.0:8000zamiast tego ustawiłem opcję http = 0.0.0.0:8000. socketopcja przeznaczona do użytku z niektórymi routerami innych firm (na przykład nginx), podczas gdy gdy httpopcja jest ustawiona, uwsgi może akceptować przychodzące żądania HTTP i samodzielnie je kierować.

Prawidłowym rozwiązaniem nie jest przełączanie się na protokół HTTP. Wystarczy zwiększyć rozmiar bufora w ustawieniach uWSGI.

buffer-size=32768

lub w trybie linii poleceń:

-b 32768

Cytat z oficjalnej dokumentacji:

Domyślnie uWSGI przydziela bardzo mały bufor (4096 bajtów) dla nagłówków każdego żądania. Jeśli zaczniesz otrzymywać w swoich logach „nieprawidłowy rozmiar bloku żądań”, może to oznaczać, że potrzebujesz większego bufora. Zwiększ go (do 65535) za pomocą opcji rozmiaru bufora.

Jeśli otrzymujesz w swoich dziennikach wartość „21573” jako rozmiar bloku żądań, może to oznaczać, że używasz protokołu HTTP do komunikacji z instancją używającą protokołu uwsgi. Nie rób tego.

Stąd: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

Natknąłem się na ten sam problem, próbując uruchomić go pod nginx i postępowałem zgodnie z dokumentami tutaj . Należy zauważyć, że po przełączeniu się na nginx należy upewnić się, że nie próbujemy uzyskać dostępu do aplikacji na porcie określonym przez parametr --socket, ale na porcie „nasłuchiwania” w nginx.conf. Chociaż twój problem jest opisany inaczej, tytuł dokładnie pasuje do tego, co miałem.

Mogłem to naprawić dodając --protocol = http do uwsgi

Ten błąd jest wyświetlany, gdy serwer uWSGI używa uwsgiprotokołu i próbuje się uzyskać do niego dostęp za pośrednictwem httpprotokołu bezpośrednio przez curlprzeglądarkę internetową. Jeśli możesz, spróbuj skonfigurować serwer uWSGI do korzystania z httpprotokołu, aby uzyskać do niego dostęp przez przeglądarkę internetową lub curl.

Jeśli nie możesz (lub nie chcesz) tego zmienić, możesz użyć odwrotnego proxy (np. nginx) Przed lokalnym lub zdalnym serwerem uWSGI, zobacz https://uwsgi-docs.readthedocs.org/en/latest/Nginx .html

Jeśli wydaje ci się, że za dużo pracy, wypróbuj uwsgi-toolspakiet Pythona:

$ pip install uwsgi-tools

$ uwsgi_curl 10.0.0.1:3030

Istnieje również prosty odwrotny serwer proxy, uwsgi_proxyjeśli chcesz uzyskać dostęp do aplikacji za pośrednictwem przeglądarki internetowej itp. Zobacz bardziej rozszerzoną odpowiedź https://stackoverflow.com/a/32893520/179581

Jak wskazano w innym komentarzu z dokumentów:

Jeśli otrzymujesz w swoich dziennikach wartość „21573” jako rozmiar bloku żądań, może to oznaczać, że używasz protokołu HTTP do komunikacji z instancją używającą protokołu uwsgi. Nie rób tego.

Jeśli używasz Nginx, nastąpi to, jeśli masz taką konfigurację (lub coś podobnie dziwnego):

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

to jest rozmowa HTTP do uWSGI (co sprawia, że ​​jest zrzędliwy). Zamiast tego użyj:

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

człowiek mam ten sam problem; więc zrobiłem to ... spójrz na 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: aplikacja

master = prawdziwe procesy = 33 rozmiar bufora = 32768

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

2 - dokonaj poważnej aktualizacji wydajności na nginx ... dane www użytkownika;

work_processes auto; work_processes 4; pid /run/nginx.pid; dołącz /etc/nginx/modules-enabled/*.conf;

zdarzenia {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;

## # Podstawowe ustawienia ##

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; # server_name_in_redirect off;

dołącz /etc/nginx/mime.types; default_type application / octet-stream;

## # Ustawienia SSL ##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Porzucenie SSLv3, ref: POODLE ssl_prefer_server_ciphers on;

## # Ustawienia rejestrowania ##

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

## # Ustawienia Gzip ##

gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied
wygasł no-cache no-store private auth; gzip_types text / zwykła aplikacja / 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 tekst / zwykły tekst / aplikacja css / aplikacja json / tekst javascript / aplikacja xml / aplikacja xml / xml + tekst rss / javascript;

## # Konfiguracja wirtualnego hosta ##

dołącz /etc/nginx/conf.d/ .conf; include / etc / nginx / sites-enabled / ; }

3 - wtedy ... zrestartuj usługi lub uruchom ponownie serwer ...

systemctl restart uwsgi & systemctl restart nginx