Odoo 19 部署：Worker 如何扩容才不踩内存坑

Odoo 性能高度依赖并发处理方式。用户一多，仪表板变慢、报表变慢、后台任务抢资源——往往与 Worker 配置有关。Odoo 19 生产环境应使用多进程，而不是开发用的多线程模式。

对照：How to Scale Workers in an Odoo 19 Deployment。

一、为什么 Worker 配置重要

默认多线程模式适合开发/演示/测试，难以吃满硬件。Linux 生产应开多进程，以便并行处理请求。配置不当会出现：页面慢、请求超时、报表慢、后台延迟、资源占用异常升高。

二、Worker 类型

1. HTTP Workers

处理用户与 API 请求（打开表单、创建记录、看板、报表等）。由 odoo.conf 中 workers 控制，例如 workers = 4。

2. Cron Workers

处理计划动作、定时邮件等，由 max_cron_threads 控制（如 max_cron_threads = 2）。多进程模式下与 HTTP Worker 分离。

3. Live Chat / WebSocket Worker

多进程模式会启动专用 Live Chat Worker，监听 gevent 端口做实时通信。反代时需把 WebSocket 正确转到该 Worker。

三、如何估算 Worker 数量

没有放之四海皆准的数字，需综合考虑 CPU、内存、并发用户、自定义模块与负载。

常用经验公式：

workers = (CPU 核数 × 2) + 1

• 2 核 → 约 5
• 4 核 → 约 9
• 8 核 → 约 17

另有约“每 Worker 支撑约 6 个并发用户”的粗略说法。这些都是起点，必须在真实负载下监测后再调。

四、内存考量

轻量 Worker 可能约 150MB，重负载可能到约 1GB 量级（视模块与请求而定）。规划 RAM 时要同时留给 PostgreSQL 与操作系统。

可用限制参数：

• limit_memory_soft / limit_memory_hard
• limit_time_cpu / limit_time_real

防止单个 Worker 吃光资源或请求跑太久。

五、超出单机：水平扩展

加 CPU/RAM/Worker 属于垂直扩展。不够时可用多台应用服务器 + Nginx/HAProxy 负载均衡。需考虑：共享 filestore 或对象存储、PostgreSQL 容量与连接、WebSocket 路由、会话策略、节点间均衡。

六、监控

配置后在真实负载下观察进程与资源，例如：

ps aux | grep odoo | grep -v grep
watch -n 2 'ps aux --sort=-%mem | grep odoo'

同时监控 CPU、RAM、PG 连接数、响应时间与 Odoo 日志。

七、小结与 FAQ

扩容要平衡 CPU、内存、数据库与用户数。Worker 越多并发越高，但也更吃资源；配过头会导致内存与数据库连接压力过大。

Worker 是什么？处理请求的进程，使多人可同时使用系统。
设多少？看 CPU/RAM/用户/负载，可用公式作起点再压测。
太多会怎样？会占用更多 CPU、RAM 与数据库连接，反而伤性能。

中国Odoo网原创中文改写｜保留公式/类型/内存/多机/监控/FAQ。Odoo用户手册 · 中文文档 · 部署实操。