ERP 服务器规模调整：如何正确调整

ERP 的服务器规模是一种看似技术性的决策，但会产生重大的业务后果。如果服务器规模过小，您从第一天起就会收到性能投诉 - 页面加载缓慢、高峰使用期间超时以及并发负载下的数据库死锁。如果规模过大，您就会在大部分闲置的基础设施上花费远远超过必要的费用。

大多数 ERP 实施都会在以下两个方向之一上出现服务器规模错误：过于自信的 IT 团队根据“这只是一个 Web 应用程序”的直觉来确定规模，而不考虑 ERP 的数据库强度，或者根据供应商的建议进行校准，不惜任何成本以获得最佳性能，而不是以合理的成本获得适当的性能。

本指南为您提供了一种结构化的 ERP 部署服务器规模调整方法：驱动资源需求的关键变量、不同用户数量下主要 ERP 平台的具体规模调整准则，以及如何使用 ECOSIRE 的免费服务器规模计算器来模拟您的具体情况。

要点

• ERP 的数据库密集程度明显高于典型的 Web 应用程序 — 标准 Web 服务器大小调整规则不适用
• CPU 很少成为限制； RAM 和磁盘 I/O 几乎始终是 ERP 工作负载的瓶颈
• Odoo 每个并发工作进程需要 2–4 GB RAM；对于具有 50 名以上用户的生产实例，至少 16 GB
• 在大多数服务器规模调整练习中，数据库存储 IOPS 要求被大大低估
• 纸面上看起来相当的云实例（相同的 vCPU、相同的 RAM）可能具有截然不同的 I/O 性能
• 始终根据峰值并发负载（而非平均负载）调整大小，并留出 30–40% 的空间
• 使用 ECOSIRE 的免费服务器规模计算器为您的特定用户数量和 ERP 平台生成规范

---

为什么 ERP 服务器规模不同

在深入研究具体建议之前，有必要了解为什么 ERP 服务器规模调整需要比典型 Web 应用程序的规模调整进行更仔细的分析。

数据库强度：ERP 系统本质上是事务处理系统。每个用户操作（创建采购订单、过帐发票、移动库存）都会生成必须自动提交的多个数据库写入操作。数据库层处理大型规范化模式中的复杂关系查询，通常使用多个表连接和聚合计算。这与内容管理系统或营销网站非常不同，内容管理系统或营销网站可能会从每个页面视图的一些非规范化表中读取数据。

并发用户负载模式：ERP 用户行为比典型 Web 应用程序更加并发。在消费者网站中，用户独立浏览，交互不频繁。在 ERP 系统中，同一部门的多个用户可能会在高峰时段（月末、日终、轮班结束）同时处理订单。这种并发写入模式会产生典型 Web 应用程序从未遇到的数据库锁争用。

报告生成工作负载：ERP 报告（尤其是财务报告、库存账龄和需求预测）执行复杂的多表查询，这些查询可能运行 30-120 秒，并在执行期间消耗大量 CPU 和 I/O。当三名财务人员同时运行月末结算报告时，所产生的负载峰值可能会很严重。

会话状态和工作进程：Odoo 专门运行 Python 工作进程来维护每个活动用户连接的会话状态。每个工作进程在稳定状态下消耗大约 200–400 MB RAM，在大量报告执行期间消耗最多 1 GB。服务器需要足够的 RAM 来同时运行所有活动工作线程，而无需交换到磁盘 - 在 ERP 数据库服务器中进行交换会导致灾难性的性能下降。

---

ERP 服务器规模调整中的关键变量

有四个变量比其他任何变量更能驱动 ERP 服务器资源需求：

1.并发用户数（不是总用户数）

用户总数不能很好地预测资源需求。正确的指标是峰值并发用户数：在一天中最繁忙的时段同时主动向系统发出请求的用户数量。

根据总用户数估计峰值并发用户数：

• 正常营业时间的基于办公室的 ERP：高峰时并发用户总数的 15–25%
• 多班次制造：25–35% 的总用户并发（换班峰值）
• 跨时区分布式操作：峰值并发量较低，但峰值持续时间较长
• 月底财务使用量大：在关闭期间并发量暂时飙升至 40-50%

对于正常办公室使用的 100 个用户 Odoo 部署，在典型高峰期规划 15-25 个并发用户，并在月底提供 40-50 个并发用户。这应该驱动您的规模计算，而不是 100 个用户的总数。

2.交易量和交易复杂性

高事务量会独立于并发用户驱动数据库写入负载。每天处理 2,000 个采购订单的分销公司产生的数据库写入 I/O 明显多于拥有 100 个用户但交易量较低的专业服务公司。同样，复杂事务（同时更新 BOM 消耗、库存、成本核算和质量记录的制造工作订单）比简单事务（更新两个总账科目的日记帐分录过帐）生成更多的 I/O。

通过考虑使用的模块来估计您的交易复杂性：制造和多仓库库存生成最复杂的交易；简单的会计和人力资源模块生成最简单的。

3.数据库大小和增长率

数据库大小以两种方式影响查询性能：直接（较大的表需要更长的扫描时间）和间接（超过可用 RAM 的工作集导致缓存未命中和 I/O 增加）。

ERP 数据库的增长速度超出了大多数 IT 团队的预期。随着交易历史记录、文档附件和审核日志的正常增长，20 GB 的起始数据库可以在两到三年内达到 100 GB。根据三年的预期增长来调整存储容量，而不仅仅是当前的需求。

4.集成和 API 工作负载

如果您的 ERP 通过 API（电子商务平台、3PL 系统、银行 API、市场连接器）连接到外部系统，这些集成会产生额外的服务器负载，但不会反映在用户数量中。每个 API 调用都会经过 ERP 的应用程序层和数据库 - 高容量集成（每小时处理 1,000 个订单同步请求）可以匹配 10-20 个并发用户的负载。

---

按平台和用户数量划分的规模指南

Odoo 19 企业版

Odoo 的架构使用工作进程（Odoo 工作进程），每个进程都为用户请求提供服务。所需的工作人员数量和服务器资源随并发用户数而变化。

Odoo 工人计算：

• 推荐工人数=（并发用户数/6）+1，四舍五入
• 每个工作人员在稳定状态下需要大约 300–500 MB RAM，在大量报告期间最多需要 1 GB
• Cron 工作人员（用于后台进程）添加 2–4 个额外工作人员

按用户数量推荐的最低规格：

有关 Odoo 尺码的重要说明：

• 数据库 (PostgreSQL) 和应用程序 (Odoo 工作进程) 理想情况下运行在超过 100 个用户的单独服务器上。数据库和应用程序合并在一台服务器上，会争夺 RAM。
• PostgreSQL 共享内存 ( effective_cache_size ) 应设置为数据库服务器 RAM 的 50–75%。
• SSD 存储对于 PostgreSQL 数据目录是强制性的 - 旋转磁盘会对任何 ERP 数据库造成灾难性的性能。
• 对于超过 50 个用户的部署，建议使用单独的 Redis 服务器用于 Odoo 会话存储。

Microsoft Dynamics 365 商业中心

使用 SaaS 部署模型时，Business Central 在 Microsoft Azure 基础设施上进行云托管 - 在这种情况下，服务器大小由 Microsoft 管理。对于本地部署：

Business Central 本地使用 SQL Server 作为数据库，它具有与 PostgreSQL 不同的内存管理模型。将专用 RAM 分配给 SQL Server 的缓冲池（通过 max server memory 设置）— 大约是数据库服务器 RAM 的 75%。

SAP 业务一号

SAP Business One 部署在本地（Windows 或 HANA）或 SAP Business One Cloud 上：

SAP HANA（与 SAP Business One HANA 版本一起使用的内存数据库）比传统的基于磁盘的数据库具有更高的 RAM 要求，因为工作集必须适合内存。 HANA 的 RAM 要求是不容协商的 — 内存不足的 HANA 会崩溃，而不是降级。

---

云实例推荐

在 AWS、Azure 或 GCP 上自托管 ERP 时，选择正确的实例类型非常重要。并非所有具有相同 vCPU 和 RAM 数量的实例对于数据库工作负载的性能都相同。

AWS 对 Odoo 的建议（应用程序 + 数据库组合，100 个用户以下）：

• t3.xlarge（4 vCPU，16 GB）：开发和小规模生产（25 个用户以下）
• r6i.xlarge（4 vCPU，32 GB）：中小型生产（25-50 个用户）
• r6i.2xlarge（8 vCPU，64 GB）：中等生产（50–100 个用户）
• r6i.4xlarge（16 vCPU，128 GB）：大型生产（100–200 个用户，合计）

AWS 针对 Odoo 的建议（拆分应用程序/数据库，100 多个用户）：

• 应用程序服务器：c6i.2xlarge（8 个 vCPU，16 GB）— 计算优化
• 数据库服务器：r6i.4xlarge（16 个 vCPU，128 GB）— 内存优化
• 数据库存储：io2 EBS 卷（已配置 IOPS）— 已配置 3,000–6,000 IOPS

Azure 等效项：

• 应用程序服务器：Standard_F8s_v2（8 个 vCPU，16 GB）
• 数据库服务器：Standard_E16s_v5（16 vCPU，128 GB）

GCP 等效：

• 应用程序服务器：c2-standard-8（8 个 vCPU，32 GB）
• 数据库服务器：n2-highmem-16（16 vCPU，128 GB）

I/O 性能陷阱：AWS 上的标准 EBS gp3 卷默认提供 3,000 IOPS。对于具有 50 多个并发用户的生产 ERP 数据库，这通常是不够的 - 特别是在月末关闭期间，多个复杂报告同时运行。使用 io2 配置的 IOPS 卷作为数据库存储，至少配置 3,000 IOPS。成本差异很大（gp3 为 0.065 美元/GB/月，io2 为 0.125 美元/GB/月，加上预配置 IOPS 为 0.065 美元/IOPS/月），但性能差异也很大。

---

高可用架构

对于停机会对业务产生重大影响的生产 ERP 系统，请考虑采用高可用性架构，该架构可针对单服务器故障提供恢复能力。

Odoo 的最低 HA 架构（100+ 用户）：

• 负载均衡器后面的两个应用程序服务器（循环或粘性会话）
• 带有备用副本的 PostgreSQL 主数据库（使用流复制或 AWS RDS 多可用区）
• 用于会话存储的Redis集群（两个节点）
• Odoo 文件附件数据的共享文件存储（AWS EFS 或等效文件）

该架构可以针对任何单个服务器故障提供恢复能力，而无需手动干预。从主 PostgreSQL 到备用数据库的故障转移是自动的（使用 Patroni 或 AWS RDS），通常在 30-60 秒内完成。

典型 ERP 的 RPO 和 RTO 目标：

• 恢复点目标（最大数据丢失）：5 分钟（使用同步复制）到 30 分钟（使用异步复制）
• 恢复时间目标（最长停机时间）：自动故障转移 30–60 秒，手动恢复 15–30 分钟

---

使用 ECOSIRE 服务器规模计算器

ECOSIRE 的免费服务器大小计算器（位于 /tools/server-sizing-calculator）可自动执行上述计算过程。输入：

1、ERP平台选择 2. 用户总数 3. 峰值并发用户百分比（或根据用例自动估计） 4. 交易量（低、中、高、非常高） 5. 整合次数和数量（无、基本、中等、强化） 6、可用性要求（单机、HA、容灾） 7. 云提供商偏好（AWS、Azure、GCP 或本地）

输出：

• 应用程序层和数据库层的推荐服务器规格
• 为您的首选提供商提供特定的云实例建议
• 每月基础设施成本估算
• 三年增长预测显示您何时需要升级
• 存储 IOPS 要求和推荐的存储层

---

常见问题

如果我们以前从未使用过 ERP，如何估算峰值并发用户数？

对于没有历史数据的新建实施，使用总用户的 20% 作为正常办公室部署的起始估计。如果您有多个班次或跨多个时区工作，请使用 25-30%。然后在前两年增加 50% 的增长空间。对于正常办公时间的 100 个用户 ERP，在典型峰值时规划 20 个并发用户，配置 30 个，并在不更改基础设施的情况下将容量建设到 40 个。随着上线后几个月采用率的提高，这种余量方法可以避免性能问题。

我们应该在同一台服务器还是单独的服务器上运行 Odoo 应用程序和数据库？

对于 50 个用户以下的部署，单个组合服务器通常就足够了 - 该规模的应用程序和数据库工作负载通常不会发生冲突。对于 50-100 个用户，决定取决于使用模式：如果用户群全天均匀分布，没有明显的高峰期，则组合服务器可能仍然可以工作。如果存在高峰（月末、轮班结束），单独的应用程序和数据库服务器可以提供更好的隔离。超过 100 个用户，强烈建议使用单独的服务器。

Odoo 数据库应该使用什么存储类型？

SSD 存储对于 PostgreSQL 数据目录是必需的 — 旋转磁盘 (HDD) 在任何生产 ERP 数据库上都会产生不可接受的性能。在云平台上，如果并发用户超过 50 个，请使用预配置 IOPS SSD（AWS io2、Azure Premium SSD v2、GCP Extreme Persistent Disk）作为数据库存储。通用 SSD（AWS gp3、Azure 标准 SSD）适用于 25 个并发用户以下的开发和小型生产部署。

我们应该在服务器规模调整中增加多少空间？

在正常运营情况下，建立高于预期峰值负载 30-40% 的净空，并在月末关闭或销售旺季等特殊时期建立 100% 的净空（实际上是峰值容量的两倍）。云部署可以使用自动扩展来处理特殊时期，而无需永久支付该容量的费用，这与固定的本地基础设施相比具有显着的成本优势。

---

后续步骤

使用 ECOSIRE 的免费服务器大小计算器（位于 /tools/server-sizing-calculator）为您的特定部署生成规范。该计算器会输出 AWS/Azure/GCP 实例建议和每月基础设施成本估算，您可以将其用于预算规划。

如果您正在规划 Odoo 实施，并希望 ECOSIRE 在实施的同时处理基础设施规模调整和设置，则基础设施规划包含在每个 ECOSIRE 实施活动中。