Come dire a uWSGI di preferire i processi ai thread per il bilanciamento del carico

Question

Ho installato Nginx + uWSGI + Django su un VDS con 3 core CPU. uWSGI è configurato per 6 processi e 5 thread per processo. Ora voglio dire a WSGI di utilizzare i processi per il bilanciamento del carico fino a quando tutti i processi sono occupati e quindi utilizzare i thread se necessario. Sembra che uWSGI preferisca i thread e non ho trovato alcuna opzione di configurazione per modificare questo comportamento. Il primo processo richiede oltre il 100% di tempo di CPU, il secondo richiede circa il 20% e altri processi non vengono utilizzati per lo più.

Il nostro sito riceve 40 r/s. In realtà anche avere 3 processi senza thread è utile per gestire tutte le richieste di solito. Tuttavia, l'elaborazione delle richieste si blocca di volta in volta per vari motivi, ad esempio le risorse condivise bloccate, ecc. In questi casi, abbiamo il processo -1. Gli utenti non amano aspettare e fare clic sul collegamento ancora e ancora. Di conseguenza tutti i processi si bloccano e tutti gli utenti devono attendere.

Vorrei aggiungere ancora più thread per rendere il server più robusto. Ma il problema è probabilmente Python GIL. Threads non utilizzerà tutti i core della CPU. Quindi più processi funzionano molto meglio per il bilanciamento del carico. Ma i thread possono aiutare molto nel caso di risorse condivise bloccate e I/O attendere i ritardi. Un processo può fare molto lavoro mentre uno dei suoi thread è bloccato.

Non voglio ridurre i limiti di tempo finché non ci sono altre soluzioni. È possibile risolvere questo problema con i thread in teoria, e non voglio mostrare all'utente i messaggi di errore o fargli aspettare ogni richiesta fino a quando non c'è altra scelta.

Answer 1

Quindi, la soluzione è:

1. aggiornamento uWSGI alla recente versione stabile (come suggerito roberto).
2. Utilizzare l'opzione --thunder-lock.

Ora sono in esecuzione con 50 thread per processo e tutte le richieste sono distribuite equamente tra i processi.

Answer 2

Ogni processo è effettivamente un thread, poiché i thread sono contesti di esecuzione dello stesso processo.

Per tale motivo non c'è niente come "un processo viene eseguito anziché un thread". Anche senza thread il processo ha 1 contesto di esecuzione (una discussione). Quello che vorrei indagare è il motivo per cui si ottengono (percepite) scarse prestazioni quando si usano più thread per processo. Sei sicuro di usare una versione stabile di uWSGI (con supporto solido per il threading)? (1.4.xo 1.9.x)

Hai mai pensato di generare dinamicamente più processi quando il server è sovraccarico? Controlla le modalità più economiche di uWSGI, sono disponibili vari algoritmi. Forse uno si adatta alla tua situazione.

Il GIL non è un problema per te, poiché da quello che descrivi il problema è la mancanza di thread per la gestione di nuove richieste (anche se dai tuoi numeri sembra che si possa avere una contesa troppo pesante di blocco su qualcos'altro)