用threading 解决 gunicorn worker timeout

本文探讨了Gunicorn中workertimeout的问题及其解决方案。通过调整线程管理和使用threading模块,有效避免了长时间运行的任务导致的工作进程被杀掉的情况。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

         产生worker timeout 的背景

        while 1:

              .....

              time.sleep(1)

       gunicorn运行起来,只等待了30s,就卡住了,没报任何异常或err,查了gunicorn 官方文档,原来是线程默认等待30s 就kill 掉,再restart

       http://docs.gunicorn.org/en/stable/settings.html

       

timeout

  • -t INT, --timeout INT
  • 30

Workers silent for more than this many seconds are killed and restarted.

Generally set to thirty seconds. Only set this noticeably higher if you’re sure of the repercussions for sync workers. For the non sync workers it just means that the worker process is still communicating and is not tied to the length of time required to handle a single request.

 

         根本原因找到了,在gunicorn启动加了--timeout  120 ,还是超过30s 就worker timeout.搜了一圈stack没发现好的解决方法。

        解决这个问题,目前最好的方法,就是在程序改代码,原先是主线程调用,用threading包装一下

        如:

         import threading

         t = threading.Thread(name = '', target = func ,kwargs{})

         t.daemon = True

         t.start()

         

          t = threading.Thread(name='result_package', target=result_package, args=(pack_name, task, issue))

   t.daemon = True
    t.start()

                 

           这样就在主线程下,把方法包装起来。

           顺便用

           Event().wait(15)  替代 time.sleep(16)

     这样写法的好处是不占用cpu,释放!

          

           刚开始,分析原因花了不少时间,几行代码就把worker timeout解决了。之前试了map.thread不行。

          准备用队列(celery+redis)替代原来的逻辑,只是工作量有点大,太重了。

            

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值