Processi di spawning dei dipendenti di sincronizzazione di Gunicorn

Stiamo utilizzando Django + Gunicorn + Nginx nel nostro server. Il problema è che dopo un po 'vediamo molti dei processi di lavoro di gunicorn che sono diventati orfani, e molti altri che sono diventati zombi. Inoltre possiamo vedere che alcuni dei processi di lavoro di Gunicorn generano altri lavoratori Gunicorn. La nostra ipotesi migliore è che questi lavoratori diventino orfani dopo la morte dei loro genitori.
Perché i lavoratori Gunicorn generano lavoratori minorenni? Perché muoiono ?! E come possiamo evitare questo?
Vorrei anche ricordare che abbiamo impostato il livello di registro di Gunicorn su debug e ancora non vediamo nulla di significativo, oltre al registro periodico del numero di lavoratori, che riporta il conteggio dei lavoratori che volevamo da esso.Processi di spawning dei dipendenti di sincronizzazione di Gunicorn

UPDATE Questa è la linea che abbiamo usato per eseguire gunicorn:

gunicorn --env DJANGO_SETTINGS_MODULE=proj.settings proj.wsgi --name proj --workers 10 --user proj --group proj --bind 127.0.0.1:7003 --log-level=debug --pid gunicorn.pid --timeout 600 --access-logfile /home/proj/access.log --error-logfile /home/proj/error.log

fonte

2015-08-31 sazary

Puoi pubblicare la tua configurazione Gunicorn? È difficile capire cosa potrebbe succedere senza sapere come è stato impostato. – jnovinger

qualsiasi aggiornamento sulla tua domanda? hai trovato una soluzione o hai scoperto cosa c'era che non andava? –

questo è stato per molto tempo fa, abbiamo cambiato da gunicorn a uWSGI un giorno o due dopo che ho fatto questa domanda e non abbiamo trovato una soluzione. – sazary

Nel mio caso ho distribuire nei server Ubuntu (LTS rilascia, ormai quasi sono 14.04 LTS server) e non ho mai fatto hanno problemi con i demoni gunicorn, ho creare un gunicorn.conf.py e lanciare gunicorn con questa configurazione da parvenu con uno script come questo in /etc/init/djangoapp.conf

description "djangoapp website" 
start on startup 
stop on shutdown 
respawn 
respawn limit 10 5 

script 
    cd /home/web/djangoapp 
    exec /home/web/djangoapp/bin/gunicorn -c gunicorn.conf.py -u web -g web djangoapp.wsgi 
end script

Configuro gunicorn con una configurazione di file .py e imposto alcune opzioni (dettagli sotto) e distribuisco la mia app (con virtualenv) in /home/web/djangoapp e nessun problema con i processi di gunicorn di zombie e orfani.

ho verificato le opzioni, il timeout può essere un problema ma un altro è che non si configurano le max-richieste nella configurazione, per impostazione predefinita è 0, quindi, nessun riavvio automatico del lavoratore nel daemon e può generare perdite di memoria (http://gunicorn-docs.readthedocs.org/en/latest/settings.html#max-requests)

fonte

2015-12-28 03:24:27

Stavamo usando il supervisore, poi quando abbiamo visto il problema pensavamo che accadesse a causa del supervisore. L'abbiamo rimosso e il problema è rimasto. – sazary

ok, quindi ora le mie risposte, stai usando uwsgi e il problema rimane? quale stai usando ora invece di supervisore? –

stiamo usando il meccanismo daemonizer di uwsgi (senza supervisore) e no, il problema non rimane. – sazary

Processi di spawning dei dipendenti di sincronizzazione di Gunicorn

risposta

Problemi correlati