odoo12-addon-bus-alt-connection 12.0.1.0.0.99.dev2

Odoo的内置连接池为什么不够好？

Odoo的内置连接池在进程级别工作：每个Odoo进程都有自己的ConnectionPool，限制为db_maxconn。

它负责复用连接池中可用的打开连接。但它永远不会关闭这些连接，除非达到db_maxconn。

在实践中，我们观察到每个odoo工作进程最终将在其池中保留最多3个打开连接。对于10个HTTP工作进程，这将是仅针对单个实例持续打开的最多30个连接。

这就是PgBouncer的作用

PgBouncer将通过在实例级别共享连接池来帮助限制打开连接的数量，在所有工作进程之间共享。Odoo工作进程仍然最多保留3个打开连接，但这些将是连接到PgBouncer的连接，而PgBouncer在其一侧将关闭到pg的不必要连接。

这已被证明有助于具有多个实例的Odoo部署的性能。

它允许您根据优先级定义资源应如何共享，例如

• 主机A上的关键odoo实例可以打开最多30个连接

• 而主机B上的odoo实例，仅用于报告，只能打开最多10个连接

最重要的是，它有助于确保在pg服务器端不会达到max_connections。

为什么需要这个模块？

在配置PgBouncer时，您可以在两种事务池模式之间进行选择

• pool_mode = session

• pool_mode = transaction

如果我们选择 pool_mode = session，则一个服务器连接将绑定到特定的Odoo进程，直到其死亡，这正是我们试图改变的地方。因此，为了在事务完成后释放服务器连接，我们使用 pool_mode = transaction。

这工作得很好，但Odoo的longpolling功能依赖于来自pg的LISTEN/NOTIFY机制，该机制与该模式不兼容。

更准确地说，在那种模式下，NOTIFY语句被PgBouncer正确地传递；只有 LISTEN 语句没有（因为它需要保持服务器连接打开）。

因此，对于需要该语句的每个实例的唯一的“监听”连接（这里），我们需要Odoo直接连接到pg服务器，绕过PgBouncer。

这就是本模块实现的方式，通过覆盖Dispatcher的相关方法。

目录

安装

您不需要在数据库中安装此模块来启用它。

但您需要将其加载到服务器端

• 通过以--load=web,bus_alt_connection启动Odoo

• 或更新其配置文件

[options]
(...)
server_wide_modules = web,bus_alt_connection

配置

您需要定义如何直接连接到数据库

• 通过定义环境变量

  • IMDISPATCHER_DB_HOST=db-01

  • IMDISPATCHER_DB_PORT=5432

• 或者在Odoo的配置文件中

[options]
(...)
imdispatcher_db_host = db-01
imdispatcher_db_port = 5432

问题跟踪器

问题在GitHub Issues上跟踪。如果遇到问题，请检查那里是否已报告您的问题。如果您是第一个发现它的人，请通过提供详细且受欢迎的反馈来帮助我们解决这个问题。

请勿直接联系贡献者寻求支持或帮助解决技术问题。

致谢

维护者

此模块由OCA维护。

OCA，或Odoo社区协会，是一个非营利组织，其使命是支持Odoo功能的协作开发并推广其广泛应用。

此模块是GitHub上的OCA/server-tools项目的一部分。

欢迎您做出贡献。要了解更多信息，请访问https://odoo-community.org/page/Contribute。