Odoo 的 PostgreSQL 性能优化：调优、索引和监控

与默认设置相比，正确调整的 PostgreSQL 实例可以将 Odoo 响应时间提高 2-5 倍。 大多数 Odoo 性能问题都可以追溯到数据库配置 - 默认 PostgreSQL 设置旨在最大限度地减少资源使用，而不是为多用户 ERP 系统提供动力。

要点

• 默认 PostgreSQL 设置仅使用 128MB 共享缓冲区 - 生产 Odoo 需要 25% 的 RAM
• 频繁查询的列上缺少索引会导致全表扫描和页面加载缓慢
• 使用 PgBouncer 的连接池可减少 80% 的数据库连接开销
• 定期 VACUUM 和 ANALYZE 防止表膨胀并保持查询计划最优

---

PostgreSQL 配置调优

内存设置

使用适合您的硬件的设置编辑 postgresql.conf。对于具有 16GB RAM 的服务器，将shared_buffers 设置为 4GB（总 RAM 的 25%）， effective_cache_size 设置为 12GB（总 RAM 的 75%），work_mem 设置为每个操作 64MB，maintenance_work_mem 设置为 1GB，wal_buffers 设置为 64MB。

对于查询规划，将 SSD 存储的 random_page_cost 设置为 1.1（默认情况下为 HDD，默认为 4.0），将 SSD 的 effective_io_concurrency 设置为 200，将 default_statistics_target 设置为 200，以获得更准确的查询计划。

尺寸指南：

|服务器内存|共享缓冲区 |有效缓存大小|工作内存| |----------|--------------|----------|----------| | 4GB | 1GB | 3GB | 16MB | | 8GB | 2GB | 6GB | 32MB | | 16GB | 4GB | 12GB | 64MB | | 32GB | 8GB | 24GB | 128MB | | 64GB | 16GB | 48GB | 256MB |

连接设置

将 max_connections 设置为至少 Odoo 工作线程 x 2 加缓冲区。如果有 4 个工作线程和 2 个 cron 线程，则至少需要 12 个连接。添加管理工具、监控和后台任务的连接。值为 200 可提供舒适的净空高度。

---

Odoo 的索引策略

识别缺失索引

通过将 log_min_duration_statement 设置为 500ms 来启用慢查询日志记录。然后分析慢查询日志来识别全表扫描。

常见 Odoo 索引

Odoo 自动在主键和外键上创建索引。在经常过滤的列上添加索引，例如 sale_order(state)、account_move(state)、stock_move(state)、account_move(date) 和 sale_order(date_order)。

多列索引改进了常见的过滤器组合：account_move_line(account_id, date) 和 stock_quant(product_id, location_id)。

对于具有状态列的表，活动记录上的部分索引更有效——仅对状态未取消或完成的行进行索引。

---

使用 EXPLAIN ANALYZE 进行查询分析

对慢速查询运行 EXPLAIN (ANALYZE, BUFFERS) 以了解执行计划。寻找：

• 顺序扫描：全表扫描表明缺少索引
• 嵌套循环：对于大型结果集可能会很昂贵
• 排序：内存中排序超过 work_mem 溢出到磁盘
• 缓冲区共享读取：高值意味着数据未缓存

常见的性能杀手：

1. WHERE 子句列上缺少索引
2. Odoo ORM 生成的大型 IN 子句
3. 存储的计算字段在写入时触发重新计算
4. Complex report queries joining 5+ tables

---

真空和维护

更新或删除行时，PostgreSQL MVCC 会创建死元组。 VACUUM 回收该空间并更新统计数据。

为 Odoo 工作负载配置 autovacuum：启用 autovacuum，最多 3 个工作人员、60 秒的午睡时间、vacuum 比例因子为 0.05，并分析比例因子为 0.02。对于高写入表（account_move_line、stock_move、mail_message），设置更积极的每表设置。

通过检查总关系大小和死元组计数来监视表膨胀。仅在极端膨胀（超过 50% 的死空间）时使用 VACUUM FULL，并且仅在维护窗口期间使用，因为它会锁定表。

---

使用 PgBouncer 进行连接池

PgBouncer 位于 Odoo 和 PostgreSQL 之间，汇集连接以减少开销。 Odoo 使用事务池模式，释放事务之间的连接。将 default_pool_size 设置为 40，将 max_client_conn 设置为 200。将 Odoo 指向 PgBouncer 端口，而不是直接指向 PostgreSQL。

---

监控

基本指标

• 活动连接：应远低于 max_connections
• 缓存命中率：应高于 99%
• 交易率：基线并观察异常情况
• 查询计数缓慢：查询超过您的阈值
• 复制滞后：如果使用只读副本
• 磁盘使用率：数据库大小增长率
• 表膨胀：每个表的死元组比率

使用 pg_stat_statements 扩展来跟踪一段时间内的查询性能。它记录执行计数、总时间、平均时间以及每个不同查询模式返回的行数。

---

常见问题

问：我如何知道 PostgreSQL 是否是瓶颈？

启用慢查询日志记录并检查 Odoo 性能日志。如果大多数慢速请求对应于慢速查询，则调整会有所帮助。如果查询很快但 Odoo 很慢，则瓶颈在于应用程序代码或网络。

问：我应该为 Odoo 使用 PostgreSQL 副本吗？

读取副本从主数据库卸载报告查询。 Odoo 本身不支持读/写拆分，因此自定义配置将只读查询路由到副本。这主要对于非常大的部署有用。

问：Odoo 应该使用什么 PostgreSQL 版本？

使用您的 Odoo 版本支持的最新稳定版本。新版本包括查询优化器改进和更好的真空性能。建议当前 Odoo 版本使用 PostgreSQL 16 或 17。

问：适当的调整实际上有多大帮助？

根据我们的经验，从默认设置转向调整配置通常可以将平均页面加载时间提高 40-60%，并将慢速查询频率降低 80-90%。改善是显着且立竿见影的。

---

下一步是什么

PostgreSQL tuning is the single highest-impact optimization for Odoo performance.从内存设置和索引开始——仅这两项更改就可以将响应时间缩短一半。

联系 ECOSIRE 获取数据库优化帮助，或探索我们的 Odoo 支持服务 进行持续性能管理。

---

由 ECOSIRE 发布——帮助企业利用企业软件解决方案进行扩展。