Flask炼金术时间表

Question

我的后端配置是：

• Ubuntu 12.04版
• Python 2.7
• 烧瓶0.9
• 烧瓶炼金术
• 博士后9

我收到了这个错误消息：

TimeoutError: QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30

是否需要显式关闭数据库会话？当会话超出作用域时，不应该是回池的连接吗？在

Answer 1

如果在应用程序中使用debug=True，并且加载了多个出错的页面或API端点，则可能会发生这种情况。在

原因是运行调试版本的应用程序会使错误页面中的实时调试器保持打开状态。这个实时调试器保留了处理请求的所有资源，以便您可以检查它们。这意味着数据库连接无法回收。在

你不应该对你的应用程序的生产版本使用调试模式（除了这样的问题之外，这是一个安全风险），而且调试器通常无论如何也不能工作（它是为flask测试服务器而设计的，而不是与gunicorn一起工作）。因此，在prod中，解决方案是关闭调试。在

如果您在使用调试模式的dev中遇到这个问题-这是一个限制。你不应该如此猛烈地攻击开发服务器，或者你可以增加限制。请注意，当正确地回收15个连接时，它们通常足以满足大量并发请求。只有在调试中，它们才会趋于耗尽。在

Answer 2

我还必须添加@app.teardown_request方法：

@app.teardown_request
    def checkin_db(exc):
        user_store.db_session.remove()

我遵循了“官方”的安全措施Basic SQLAlchemy Application with session quick start，在几次请求后得到了sqlalchemy.exc.TimeoutError：达到大小为5的队列池限制溢出10，连接超时，超时30错误“。添加上述代码似乎解决了此问题：

• 烧瓶安全：版本3.0.0
• 烧瓶：版本1.0.2

Answer 3

Flask SQLAlchemy为您管理连接池，因此一般来说，不需要这样做。{1}但是，如果某个实例在某个地方不能执行这个请求，那么这个请求不能在某个地方执行。在

当我将Flask SQLAlchemy与apscheduler配对时，我发现自己必须显式地关闭调度器执行的作业中的会话，否则在运行几个小时之后，我会得到这个错误。在