python - 如何诊断 Pyramid 中额外的 SQLAlchemy 连接

Question

当我的应用程序运行时，我经常遇到有关连接池的问题(一个是“QueuePool limit of size 5 overflow 10 reached”，另一个是“FATAL: remaining connection slots are reserved for non-replication superuser connections” ).

我有一种感觉，这是由于某些代码没有正确关闭连接，或者其他代码贪婪地试图在不应该打开新连接的情况下打开新连接，但我使用的是默认的 SQL Alchemy 设置，所以我假设池连接默认不应该是不合理的。我们正在使用 scoped_session(sessionmaker()) 创建 session 的方式，因此支持多线程。

所以我的主要问题是是否有工具或方法可以找出连接的去向？除了能够在创建新的(不应该创建的)后立即看到之外，是否有任何明显的反模式可能会导致这种效果？

Pyramid 非常不拘一格，并且与 DB 连接，似乎有两种主要方法(看起来 Pyramid 同样支持)。在我们的案例中，我开始工作时的代码库使用了一种方法(我将其称为“全局”方法)，我们已经同意切换到另一种方法，该方法较少依赖全局变量，更多依赖 Pythonic 习语。

关于我们的架构:该应用程序包含一个存储 Pyramid 项目的存储库，然后是许多其他 git 模块的来源，每个模块都有自己的连接设置。 “全局”方式以非常非 ORM 的方式连接到数据库，例如:

(in each repo's __init__ file)
def load_database:
    global tables

    tables['table_name'] = Table(
        'table_name', metadata,
        Column('column_name', String),
    )

有一些相关的全局变量经常出现在代码中:

def function_needing_data(field_value):
    global db, tables
    select = sqlalchemy.sql.select(
        [tables['table_name'].c.data], tables['table_name'].c.name == field_value)
    return db.execute(select)

这个 tables 变量被锁定在每个 git repo 中，它添加了更多的表定义，并且全局 tables 以某种方式设法工作，提供对所有表的访问。

我们采用的方法(尽管此时，两种方法的一部分仍在代码中)是通过集中连接，将所有元数据绑定(bind)到它，然后以 ORM 方法查询数据库:

(model)
class ModelName(MetaDataBase):
    __tablename__ = "models_table_name"
    ... (field values)

(function requiring data)
from models.db import DBSession
from models.model_name import ModelName

def function_needing_data(field_value):
    return DBSession.query(ModelName).filter(
        ModelName.field_value == field_value).all()

我们已将大部分代码移至后一种方法，感觉不错，但也许我的意图是错误的。我不知道这两种方法在本质上是否有好坏之分，但这(其中一种方法)是否会成为问题的一部分，所以我们一直没有连接？有没有我应该注意的迹象？

Answer 1

当您使用 Pyramid transaction manager 时，Pyramid 似乎功能最佳(在处理连接池方面) (pyramid_tm)。这excellent article by Jon Rosebaugh对 Pyramid 应用程序通常如何设置其数据库连接以及它们应该如何设置它们提供了一些有用的见解。

在我的例子中，有必要包含 pyramid_tm 包，然后删除一些我们手动提交 session 更改的地方，因为 pyramid_tm 会在没有看到不这样做的原因时自动提交更改。

[更新]

我仍然遇到连接池问题，尽管数量要少得多。经过大量调试，我发现 Pyramid 事务管理器(如果您正确使用它)根本不是问题所在。我不得不处理通过 cron 作业运行的脚本的其他连接池问题。一个脚本在完成后会释放它的连接，但是糟糕的代码设计可能会导致相同的脚本可以打开并在前一个脚本运行时开始运行的情况(导致它们都运行得更慢，慢到足以同时运行脚本的第三个实例开始等等)。

这是一个与语言和数据库无关的错误，因为它源于糟糕的作业脚本设计，但值得牢记。在我的例子中，脚本末尾有一个“&”，这样每个实例都作为后台进程启动，等待 10 秒，然后生成另一个，而不是确保第一个作业开始并完成，然后等待 10 秒，然后开始另一个。

希望这有助于调试这个非常令人沮丧和棘手的问题。