2017-10-21 111 views
0

我使用gunicorn 19.7.1 appserver與nginx反向代理Django項目(Ubuntu 14.04機器)。成千上萬的外來gunicorn工人

ps aux | grep gunicorn | grep -v grep | wc -l收益率此刻。

鑑於在/etc/init/gunicorn.conf,我一直有-w 33。然而,即使我做了sudo service gunicorn stopsudo service gunicorn start,這些額外的工作人員仍然存在。

我該如何殺死多餘的工人?


這是怎麼發生的?

在繁忙的生產系統上,工人總數33一直正確配置。

但是幾個小時前,我在服務器上嘗試python的multiprocessing,事情就發生了。 Gunicorn工作人員吃掉了所有的記憶,並拿出了駐地redis實例。

enter image description here

我回復的變化,並設法讓一切重新聯機,除了內存之外,還沒有被釋放,我不得不應付這些傳統gunicorn工人。這是怎麼回事?

回答

1

然而,即使我做了sudo service gunicorn stopsudo service gunicorn start,這些額外的工人仍然存在。

service只管理service - 引發的過程,所以如果你開始的服務框架之外Gunicorn工人,這些工人將繼續生活,即使你stop

我該如何殺死多餘的工人?

快速的方法:

運行此命令可以列出所有gunicorn進程ID和終止它們,然後重新啓動Gunicorn:

$ pkill gunicorn 
$ sudo service gunicorn start 

更好的方法:

  1. ID通過查找父代來確認您的「所需」Gunicorn工人:

    $ sudo service gunicorn status 
    

    請注意父進程ID。我們假設它是123

  2. 保存所有 「被期望」 的員工名單的PID:

    $ echo 123 > desired_workers 
    $ pgrep -P 123 >> desired_workers 
    
  3. 保存所有的員工名單的PID:

    $ pgrep gunicorn > all_workers 
    
  4. 終止 「不需要的」 工人:

    $ cat desired_workers all_workers | sort | uniq -u | xargs kill 
    
+0

所以我選擇了更好的方法 - 它對我來說看起來更加手術。我在'/ tmp'中成功創建了所需的文件。最後,當我跑'貓desired_workers all_workers |排序| uniq -u | xargs殺死',什麼也沒有發生。具體來說,'ps aux | grep gunicorn | grep -v grep | wc -l仍然給我** 3043 **,也沒有釋放內存。有任何想法嗎? –

+0

@HassanBaig你是過程的所有者嗎?如果沒有,你可能需要'sudo kill'而不是'kill'。 –

+0

是的,我真的試過這個東西既''根'和通過'貓desired_workers all_workers |排序| uniq -u | xargs sudo殺害'。這兩種方式都不能殺死這些進程我仍然看到** 3043 **。也許應該在這裏應用不同的方法? –

相關問題