翔云

Just try, don't shy. 最新文章请点击
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

开发过程中,最郁闷的不是代码一直报错,而是明确知道代码执行有异常,但就是没有具体的错误报出来,无法进一步定位到问题的根因。

因此,平时工作中,养成良好的编码习惯是多么重要。
例如,在代码有异常的地方,打印下日志。这个看似细小的动作,会给以后排查问题带来莫大的帮助。

并且即使使用监控组件上报错误,也记得在本地打印下日志,方便问题追查。更何况,第三方监控组件可靠性不是百分之百的。万一,监控组件有个bug,把代码中的错误吞掉了。那更是增加问题排查的难度。

最近就遇到了类似的问题。
我们在代码中捕获异常后,先是使用cat 上报错误,接着将异常继续抛出。

但实际上是,cat上报错误时,将异常吞掉了,没有继续抛出异常。导致排查问题持续了很长时间。直到我们在调用cat上报错误之前,先打印下错误日志,才最终定位到了问题。

这种惨痛的教训不可谓不深刻。这已经是在cat上踩的第二个坑了。第一次是内存泄露。。。

言归正传,继续分享本文的重点:在使用sqlalchemy中遇到的报错:

QueuePool limit of size 5 overflow 20 reached, connection timed out, timeout 30

从错误,可以直观的看出,是获取连接时,由于连接的资源限制,被阻塞住了,直到30s超时。

代码中,连接配置如下:

creator = partial(creator, config=config, connect_params=connect_params)
engine = create_engine(
    'mysql://',
    pool_size=config.POOL_SIZE,
    max_overflow=config.POOL_MAX_OVERFLOW,
    creator=creator,
    pool_pre_ping=pool_pre_ping,
    strategy="contextlocal")

POOL_SIZE 是5,POOL_MAX_OVERFLOW是20。

pool_size 表示连接池中缓存的连接数,如果为0,表示缓冲池大小无限制。

max_overflow 表示超出pool_size的,允许建立的最大连接数量。如果为-1,表示无限制。

总的最大连接数 = pool_size + max_overflow

如果是在多线程中使用,并发线程数量大于 总的最大连接数,这个错误很容易报出来。

解决方法的话,有两种:

  • 适当调大参数
  • 优化应用程序代码,避免过多占用连接。

参考

sqlalchemy 官网描述 Error Messages:QueuePool limit of size overflow reached, connection timed out, timeout

engine-creation-api

stackoverflow---Sql Alchemy QueuePool limit overflow