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_hardlimit_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用户手册 · 中文文档 · 部署实操。