德国服务器跑Odoo ERP：8GB还是16GB，PostgreSQL连接数怎么

发布时间：2026-09-23 20:27:00 · 阅读：1,001

案例背景：20人外贸公司的Odoo迁移

一家做五金出口的贸易公司，团队约20人，日常同时在线的Odoo用户峰值在12人左右。原方案是某云厂商的通用型4核8GB实例，跑Odoo 17社区版加PostgreSQL 15，用了半年后出现两个典型症状：一是下午业务高峰时页面转圈，二是月底批量生成发票时数据库报「too many clients already」。运维尝试把PostgreSQL的max_connections从100调到300，结果内存被连接进程吃满，Odoo反而更慢。

问题不在硬件不够，而在配比错了。Odoo的工作进程（workers）和PostgreSQL的连接数不是各自独立调参，而是由内存约束联立求解的一组方程。下面把这次的复盘过程拆开讲。

配比公式：先算内存，再算连接

第一步：确定Odoo工作进程数

Odoo官方给出的经验公式是：workers = (CPU核心数 × 2) + 1，但这是上限参考值，实际要受内存倒推约束。每个Odoo worker的常驻内存一般在150MB到250MB之间，视模块复杂度而定；主进程加cron线程再占约200MB到300MB。

以4核为例，公式给出9个worker，但8GB内存根本撑不住。倒推算法是：

操作系统与PostgreSQL共享缓冲预留约2GB（8GB机器）；
剩余6GB ÷ 200MB ≈ 30，看似宽松，但PostgreSQL每个连接还要占5MB到10MB工作内存，且批量任务会触发排序和哈希操作放大占用。

这台机器最终定为4个worker + 1个cron线程，即配置中workers=4、max_cron_threads=1。Odoo的limit_memory_soft设为1.2GB、limit_memory_hard设为1.5GB，让超限worker被回收重启，而不是拖垮整机。

第二步：由worker数反推PostgreSQL连接池

Odoo每个worker会占用若干数据库连接，稳态下通常每worker 1到2个，加上cron线程、长连接报表模块、以及运维自己的psql会话，安全余量按每worker 3个连接估。对应关系大致是：

max_connections ≈ workers × 3 + 10（预留）

4个worker对应约22个连接，但PostgreSQL默认max_connections=100，直接沿用并不亏，真正要收紧的是Odoo侧的db_maxconn（默认64，应下调到与连接池匹配，比如16到20）。把Odoo的连接需求压到20以内，PostgreSQL的100个连接槽位就留给备份、监控和临时运维，不会互相挤兑。

德国服务器的选型与部署实操

这次迁移的硬件落在德国机房。选择德国节点的直接原因是客户和供应商集中在欧盟，法兰克福到阿姆斯特丹、巴黎的往返延迟通常在10ms到20ms量级，比从国内或美东绕行稳定得多；同时德国对数据处理的合规环境对做B2B外贸的公司更友好。

部署时的几个可落地动作：

内存优先于核心数。Odoo是内存敏感型负载，8GB跑4 worker已接近舒适区上限。若并发用户超过20人、且启用库存和MRP模块，建议直接上16GB，worker可放到6到8个，max_connections维持100到150即可，不必盲目调高。
SSD是硬指标。PostgreSQL的WAL写入和Odoo附件存储都吃IOPS，机械盘或低配云盘在批量开票时延迟会明显放大。选型时确认是NVMe或企业级SSD，而不是共享型存储。
连接池不要省。如果并发用户继续增长，优先引入PgBouncer做transaction模式连接池，把PostgreSQL真实连接数压在30以内，Odoo侧的db_maxconn同步下调。这比加内存更省钱。
网络线路看实际用途。如果运维团队在国内、需要频繁SSH和拉备份，CN2类优化线路的体感差异明显；如果只是欧洲本地用户访问，普通国际线路即可。带宽方面，Odoo本身流量不大，但附件同步和备份上传会吃带宽，不限流量的方案省心。

实操中还有两个易踩的坑：一是把PostgreSQL和Odoo放在同一台机器却给PostgreSQL分配了过大的shared_buffers（超过内存25%），导致Odoo worker被swap拖死；二是忘记设置Odoo的proxy_mode，放在Nginx后面时客户端IP全部记成127.0.0.1，审计日志失效。这两项在部署清单里应作为必查项。

选购时要对比的参数清单

CPU核心数与主频（Odoo单请求偏单线程，主频比核心数更重要）；
内存容量与是否可弹性升配；
磁盘类型（NVMe/SSD）与IOPS保障；
带宽是否不限流量、是否含CN2类优化线路；
是否支持多IP、DDoS高防（站群或对外服务场景需要）；
是否提供真机测试与24小时技术支持；
机房位置与到目标用户群的延迟实测数据。

以秀米云德国服务器为例，其欧洲核心自营机房、企业级SSD、大带宽不限流量与多IP高防的组合，比较贴合Odoo这类需要稳定IO和欧洲本地低延迟的业务；官方提供免费真机测试，可以在正式迁移前用真实数据压一遍worker与连接数配比，避免上线后返工。具体机型与价格视服务商配置而定，建议按上述清单逐项比对后再决定。

决策建议

20人以内、并发不高的Odoo部署，4核8GB配4个worker、PostgreSQL max_connections保持100、Odoo db_maxconn压到20以内，是稳妥起点；一旦并发用户超过20人或启用重型模块，直接跳到16GB并把worker提到6到8个，比事后调参省事。核心判断标准只有一条：先按内存定worker，再由worker反推连接数，任何顺序颠倒的调优都会在业务高峰暴露问题。德国节点适合欧洲业务为主、又需要国内运维可达性的团队，迁移前用真机测试验证配比，是成本最低的风险控制手段。

标签德国服务器 Odoo ERP PostgreSQL 工作进程数外贸ERP部署