属于我们的Performance & Scalability系列
阅读完整指南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 溢出到磁盘
- 缓冲区共享读取:高值意味着数据未缓存
常见的性能杀手:
- WHERE 子句列上缺少索引
- Odoo ORM 生成的大型 IN 子句
- 存储的计算字段在写入时触发重新计算
- 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 发布——帮助企业利用企业软件解决方案进行扩展。
作者
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
相关文章
AI 支持的客户细分:从 RFM 到预测聚类
了解 AI 如何将客户细分从静态 RFM 分析转变为动态预测聚类。使用 Python、Odoo 和真实 ROI 数据的实施指南。
用于供应链优化的人工智能:可见性、预测和自动化
利用人工智能改变供应链运营:需求感知、供应商风险评分、路线优化、仓库自动化和中断预测。 2026年指南。
B2B电子商务战略:2026年打造在线批发业务
通过批发定价、帐户管理、信用条款、打孔目录和 Odoo B2B 门户配置策略来掌握 B2B 电子商务。
更多来自Performance & Scalability
Webhook 调试和监控:完整的故障排除指南
通过这份涵盖故障模式、调试工具、重试策略、监控仪表板和安全最佳实践的完整指南掌握 Webhook 调试。
k6 负载测试:在发布之前对您的 API 进行压力测试
掌握 Node.js API 的 k6 负载测试。涵盖虚拟用户启动、阈值、场景、HTTP/2、WebSocket 测试、Grafana 仪表板和 CI 集成模式。
Nginx 生产配置:SSL、缓存和安全性
Nginx 生产配置指南:SSL 终止、HTTP/2、缓存标头、安全标头、速率限制、反向代理设置和 Cloudflare 集成模式。
Odoo 性能调优:PostgreSQL 和服务器优化
Odoo 19 性能调优专家指南。涵盖 PostgreSQL 配置、索引、查询优化、Nginx 缓存和企业部署的服务器大小调整。
Odoo 与 Acumatica:适合成长型企业的云 ERP
2026 年 Odoo 与 Acumatica 的比较:独特的定价模型、可扩展性、制造深度以及哪种云 ERP 适合您的增长轨迹。
在生产中测试和监控 AI 代理
在生产环境中测试和监控 AI 代理的完整指南。涵盖 OpenClaw 部署的评估框架、可观测性、漂移检测和事件响应。