Estou usando o gunicorn 19.7.1 appserver com nginx reverse proxy para um projeto Django (máquina Ubuntu 14.04).
ps aux | grep gunicorn | grep -v grep | wc -l produz 3043 no momento.
Considerando que em /etc/init/gunicorn.conf , sempre tive -w 33 . No entanto, esses trabalhadores extras persistem mesmo se eu usar sudo service gunicorn stop e sudo service gunicorn start .
Como eu mato os trabalhadores estranhos?
O que eu tentei:
sudo service gunicorn stop e sudo service gunicorn start não funcionaram.
Em seguida, tenho recomendado duas maneiras de matar trabalhadores estranhos. Eu tentei eles - eles não tiveram sucesso também. Basicamente, quando eu testo, nada acontece.
Aqui está a primeira maneira:
1) Obtenha o gunicorn pid via sudo service gunicorn status
2) Salve todos os trabalhadores 'desejados' que não serão mortos:
echo 123 > desired_workers
pgrep -P 123 >> desired_workers
3) Agora, obtenha todos os trabalhadores de gúnis em todo o mundo:
pgrep gunicorn > all_workers
4) Por último, simplesmente faça:
cat desired_workers all_workers | sort | uniq -u | xargs kill
O acima não funcionou. Da mesma forma, fazer cat desired_workers all_workers | sort | uniq -u | xargs sudo kill também não funcionou. Nem tente isso como root .
Em seguida, eu simplesmente tentei pkill gunicorn e sudo pkill gunicorn . Nada aconteceu em nenhum dos casos. O que mais posso fazer aqui?
Como foram criados os trabalhadores externos de gúnus?
A contagem de trabalhadores de 33 sempre foi configurada corretamente no meu sistema de produção ocupado.
No entanto, algumas horas atrás, eu estava tentando multiprocessamento do python no servidor e as coisas foram para o sul. Trabalhadores de Gunicorn devoraram toda a memória e também tiraram os exemplos de redis residentes.
Eu reverti a mudança e consegui colocar tudo de volta on-line, exceto que a memória não foi liberada e tive que lidar com esses legados de trabalhadores de gúnis. O que está acontecendo?