当前位置:   article > 正文

WSGI server - Gunicorn worker调度--timeout问题分析

gunicorn [critical] worker timeout (pid:18)

前一段时间遇到一个问题,gunicorn在启动之后worker一直报timeout的错误,并且一直不断地重启。开始以为是worker内部遇到什么错误才导致gunicorn不断地重启worker。
先说一下配置,worker_class我们采用的是gevent,数据库连接采用的mysql+sqlalchemy。因为在app启动时需要连接很多个数据库,遇到这个问题就一直在纠结是不是程序的bug,数据库连接太多会有问题,但程序没有任何日志打出来啊!?但是将连接数据库的数量改小一点,就不会再出现worker重启的现象了。为什么数据库连接数变小就不会timeout了呢?是不是master觉得worker的启动时间太长了,过了一定时间就直接干掉并重启?后来将配置中的timeout改大,数据库连接数改为原来的值,问题解决!

  1. 为什么会这样?
  2. 看gunicorn源码:
  1. def run(self):
  2. servers = []
  3. ssl_args = {}
  4. if self.cfg.is_ssl:
  5. ssl_args = dict(server_side=True, **self.cfg.ssl_options)
  6. for s in self.sockets:
  7. s.setblocking(1)
  8. pool = Pool(self.worker_connections)
  9. if self.server_class is not None:
  10. environ = base_environ(self.cfg)
  11. environ.update({
  12. "wsgi.multithread": True,
  13. "SERVER_SOFTWARE": VERSION,
  14. })
  15. **server = self.server_class(
  16. s, application=self.wsgi, spawn=pool, log=self.log,
  17. handler_class=self.wsgi_handler, environ=environ,
  18. **ssl_args)**
  19. else:
  20. hfun = partial(self.handle, s)
  21. server = StreamServer(s, handle=hfun, spawn=pool, **ssl_args)
  22. server.start()
  23. servers.append(server)
  24. while self.alive:
  25. **self.notify()**
  26. gevent.sleep(1.0)

重点在server初始化的过程中,由于数据库连接数量过多,这里耗费时间过久,self.notify在timeout时间内一直没有执行,导致主进程master在timeout时间过后立即回收并重启worker进程,所以会导致上面的问题。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/天景科技苑/article/detail/932821
推荐阅读
相关标签
  

闽ICP备14008679号