一家做五金批发的公司上线 ERP 时，全公司能用系统的不到二十五个人。选型逻辑顺理成章：二十五个人，2 核 4G、40G 系统盘，跑一个 PHP 写的应用绰绰有余。上线前半年确实顺畅，录客户、开单据、打发票，都很快。变化出现在一年半之后，而且不是以"变卡"的形式出现——是三件事几乎同时冒出来：月末结账时跑一张收发存汇总表要等七八分钟，浏览器一直转圈，最后要么超时要么出一张不完整的表；应用的附件与生成文档目录涨到了几十个 G，而当初整个系统盘只有 40G，没做分区规划，程序、数据库、附件全挤在一块盘上；想扩盘的时候才发现镜像和快照都是整盘做的，扩容要走停机、迁移、半夜施工这一整套流程。用户数从头到尾没变过，还是那二十五个人，但业务单据量翻了几倍，附件量翻了十倍不止。真正的错位在于：ERP 的机器不是按"有多少人用"买的，而是按"会有多少数据、多少附件、多复杂的期末报表"买的。人数接近常数，数据量是一条向上走的曲线，这两件事在选型的时候被混为一谈了。
把上面那家公司的情况拆开看，会发现一个反直觉的地方：系统出问题的时候，服务器 CPU 和内存的日常水位都很低，白天随便看一眼监控，负载曲线几乎是平的。让它难受的不是"人多了"，而是"数据多了"和"那一批报表开始了"。这两件事在 ERP 上有明确的时点——月末、季末、年末。月底最后三天，业务在集中补单据、财务在跑往来对账和库存汇总、销售在批量生成和下载发票 PDF，所有的读、写、生成、下载挤在同一个窗口里。平时的机器是空的，月末这几天的机器是满的，空和满之间差好几倍。如果选型时只看了平时的水位，就会得到"这台机器很够用"的结论，而那个结论只在一年半之内成立。所以 ERP 的容量问题，本质上不是并发问题，是曲线问题：要估的是三年后的数据规模，和期末那几天的资源争用。
把 ERP 的负载画成一条曲线，它是这样的：白天工作时段有一个平稳的、不高的平台，这个平台由大量短小的写事务和查询构成——录一张订单、改一条库存、查一个客户、存一张发票。这些操作的共同特点是单条请求消耗的资源很少，事务很短，连接数也有限，几十个人的公司通常只有几十个数据库连接在活动。晚上和周末几乎归零。然后月末、季末、年末出现几个明显的尖峰，尖峰的构成不是"很多人同时点按钮"，而是"少数几个很重的查询和批量任务同时跑"。这与网校类系统的负载形状完全不同：网校要应付的是开票或提交截止那一刻所有人同时点提交，那是秒级的、由并发数决定的峰值，瓶颈在 Web 层的连接与排队；ERP 没有这种秒级洪峰，它的痛点是分钟级的长查询占住数据库资源不放。因此在 ERP 上，堆 Web 层的并发能力几乎没有收益，把钱花在数据库的内存、磁盘的 IO 能力和容量规划上才有收益。这个判断直接决定了后面的配置取舍。
把一台跑 ERP 的机器拆开，至少有五个组件在消耗同一份 CPU、内存和 IO。第一个是 Web 与 PHP 层：它负责页面渲染、表单处理和权限校验，常态开销小，但每起一个 PHP-FPM 进程就占一份内存，进程数乘单进程内存就是这层的常驻占用。第二个是数据库：它承担绝大部分的读和写，并且希望热数据尽量留在缓冲池里，热数据一旦被换出，所有操作都会变慢。第三个是附件目录：Dolibarr 把上传的文件和生成的 PDF、ODT 都放在配置文件里定义的文档目录中，默认在安装目录下的 documents 里，这个目录既有读也有写，而且只增不减。第四个是定时任务与邮件：官方的计划任务模块需要每 5 分钟从外部触发一次，任务包括催款提醒邮件、周期性发票生成、临时文件清理、数据库转储等，它们平时安静，但触发瞬间会同时吃 CPU 和写 IO。第五个是 PDF 生成：Dolibarr 用 PHP 的 PDF 库（TCPDF）在服务端逐行绘制单据并写入文档目录，这是一个偏 CPU 和内存的活，生成大批量发票时会形成一段持续的压力，并且同时向磁盘写入大量小文件。这五样东西在一台机器上共用 CPU、内存和同一份磁盘 IO，任何一样失控都会牵连其余四个，这也是"分盘还是分机"这个问题必须被单独讨论的原因。
Dolibarr 采用模块化结构，功能是在"设置 - 模块"里逐个启用的，启用之后还要给对应用户补权限，官方建议先启用再配权限。这个设计带来一个工程上的后果：启用哪些模块，直接决定了一张单据保存时要写多少张表。只开客户与发票的轻量用法，保存一张发票基本就是往单据表和单据明细表写几行；一旦启用库存管理，同一张发票还要产生库存移动记录；再启用复式记账，还会生成会计分录；启用银行与对账，又多一层关联记录。也就是说，同一张业务单据，随着模块开启数量的增加，会从一个小事务变成一个跨多张表的大事务。模块开得越多，单次保存的写入量越大、锁的持有时间越长、月末批量生成时的累积压力越高。反过来，模块开得少，页面渲染时的菜单构建与权限检查也更轻。所以给 ERP 定配置之前，第一件事不是看 CPU，是把要启用的模块清单确定下来，把"我们到底会用到哪几个模块"写清楚，再按这个清单元估写入路径。这也是为什么不建议一次把模块全开——开了不用，成本也是照付的。
容量估算应该是一个可代入的公式，而不是一句"大概几百 G"。ERP 的存储增长可以拆成三块相加。第一块是业务数据，等于各类单据的年发生条数乘以每条记录及其关联记录占用的字节数，这里要提醒的是"关联记录"不能漏——一张发票不只是发票表的一行，还有明细行、库存移动行、会计分录行，模块开得越多，乘数越大。第二块是上传附件，等于各类单据的年条数乘以附附件比例，再乘以平均附件个数和平均单个附件大小。第三块是系统生成的文档，等于各类单据年条数乘以生成 PDF 的比例再乘以平均单个 PDF 的大小。三年后的容量等于初始容量加上年增长乘以三，如果业务本身还在增长，还要再乘一个增长系数。这个式子里的每一个系数都必须在自己的环境里量：每类单据一年多少条，从现有系统或 Excel 台账里就能数出来；每条记录占多少字节，可以在数据库里用行数与数据长度的比值去算，用系统表或 SHOW TABLE STATUS 一类的手段都能拿到；平均附件大小，把你现在的扫描件和 PDF 拉一批出来求个平均值就有了。算出来之后按 1.5 倍留余量，因为估算会偏乐观。这套式子的价值在于它是可复算的：明年业务量变了，把数字换进去重算一遍就行，而不是重新拍脑袋。
Dolibarr 官方 wiki 的先决条件页面给过一组很有参考价值的量级：程序文件大约占 150 MByte 磁盘，数据库文件大约 35 MByte，数据库规模大约是"每 100 个客户/供应商/发票不足 1 MB"，PHP 需要允许 128 MB 的内存上限（memory_limit），CPU 方面低配机器即可运行，超过 30 个用户时建议 1GHz 以上。这组数字的作用是把"能不能跑起来"这件事讲清楚——它说明 ERP 并不是一个吃资源的重型应用，入门门槛很低。但它不能拿来当容量规划的依据，原因有三：其一，35 MByte 描述的是初始数据库的量级，不是跑三年之后的量级；其二，每 100 个客户/供应商不足 1 MB 说的是主数据，而 ERP 里真正膨胀的是交易数据和库存移动记录，不是主数据；其三，官方对附件目录没有给任何数字，只是明确说"需要的空间取决于上传文件的数量与大小"。换句话说，官方把不确定性最大的那一块明确地留给了使用者自己去算。所以正确的用法是：用官方数字定启动配置的下限，用自己代入的公式定三年容量。另外，版本兼容性也要一并核对：官方的版本兼容表显示，Dolibarr 24.0.0 要求 PHP 最低 7.2、最高 8.5，数据库支持 MySQL 5.7.7+ 或 MariaDB 10.3+ 或 PostgreSQL 9.1.0+，具体版本区间要以你准备部署的版本对应的官方说明为准。
在 ERP 的存储构成里，数据库反而容易估，附件目录才是真正的黑箱。原因在于附件的三个特性。第一个特性是单个体积不可控：一张 A4 纸的彩色扫描件，根据扫描仪设置的分辨率与色彩模式不同，单页体积可以从几百 KB 到几 MB 量级，同一台扫描仪换个设置就差好几倍，这个数字必须在你自己的扫描流程上实测，套别人的数字一定错。银行对账单的导出文件、供应商的盖章回传件、客户的签收单，也都在这个量级区间里。第二个特性是不可压缩：JPEG 本身已经是压缩格式，PDF 里内嵌的图像多数也已经压缩过，对这些文件做 gzip 几乎没有收益，指望"压缩一下就小了"是不现实的。第三个特性是不可删除：单据附件承担着业务凭证和留痕的作用，不能像应用日志那样设个保留期定期清理，删掉的代价是业务上无法追溯。三条合起来，附件目录是一条只增不减的单调上升曲线，而且斜率由一线同事的扫描习惯决定——你没法通过运维手段把它压下来。可控的手段只有两个：在业务侧制定附件规范（明确扫描分辨率、彩色还是黑白、每单允许附几个文件），在架构侧把附件目录放到独立的大容量数据盘上，让它和应用、系统盘分开增长。这两件事越早做越便宜。
报表慢这件事，用"数据多了"解释是不够的，要看它在数据库内部做了什么。典型的期末报表——比如跨期库存收发汇总、往来对账、按客户维度的销售汇总——有几个共同特征：查询条件跨越一个日期区间，涉及的表行数在几十万到几百万量级，结果集需要分组和排序。当查询条件与索引不匹配、或者需要扫描的行数占比过高时，执行计划会退化为大范围扫描，读的量远大于返回的量。分组和排序在内存里放不下的时候，数据库会把中间结果落到临时表空间，这就产生了额外的写 IO——一个"读"操作实际上制造了大量写。更麻烦的是第三点：这些大扫描会和白天的单据写入争抢同一份磁盘 IO，也会把缓冲池里的热数据冲刷出去，用大扫描的数据去替换掉业务常用的索引页和数据页。结果就是报表跑完之后的一段时间里，一线同事录单据反而比平时更慢，因为热数据已经被换出去了。这个现象解释了为什么"报表慢"会连带影响"录单慢"——它们表面上毫不相干，实际上共享同一份缓冲池和同一份 IO。也正因为如此，把报表和交易分开，或者至少给报表留出独立的资源窗口，是 ERP 部署里绕不开的一个议题。
把上述所有约束放在一起，摆法就只剩三种现实选项。第一种是全部同机同盘：Web、PHP、数据库、附件目录都在一块系统盘上。它最便宜、最简单，适合刚上线或者数据量明确的头一年，代价是没有隔离，附件把盘撑满会直接拖垮数据库，扩盘也只能整盘来。第二种是同机分盘：系统盘只放操作系统、Web、PHP 和程序文件，另挂一块数据盘放数据库和附件目录，或者数据库和附件各占一块。它增加的成本有限，但把"程序"和"数据"的增长曲线彻底分开了，附件涨满不会让系统盘跟着报警，扩数据盘也不用动系统盘。第三种是分机或分层：应用一台、数据库一台，附件目录放在独立的大容量存储上，应用与数据库之间走内网。它最灵活，报表和交易的资源争用被物理隔开，扩容可以只扩其中一层，代价是多一台机器的管理成本、内网规划、以及数据库不能暴露在公网这一安全前提。这三种摆法没有优劣之分，只有"你现在的数据量和运维能力在哪一档"之分。
| 摆放方式 | 做法 | 适合什么规模 | 代价与风险 | 什么时候必须升级到下一档 |
|---|---|---|---|---|
| 全部同机同盘 | Web 与 PHP、数据库、附件目录（Dolibarr 的 documents）都放在同一块系统盘上，不做分区隔离 | 刚上线、单据量可数、附件量小的第一年；单人维护、没有专职运维的小团队 | 无隔离，附件增长会直接占满系统盘并牵连数据库；扩盘通常要整盘停机迁移；快照为整盘，回滚粒度粗 | 系统盘使用率长期超过七成，或附件目录体积接近系统盘剩余空间时；具体阈值需实测 |
| 同机分盘 | 系统盘放操作系统、Web、PHP 与程序文件；独立数据盘放数据库与附件目录，或两者各占一块盘 | 已经跑起来、附件量开始可见增长的第二到第三年；有明确三年容量估算的成长型公司 | 应用与数据库仍共用 CPU 与内存，月末报表与单据写入仍争抢同一份 IO；需自行规划挂载点与权限 | 月末报表跑完之后录单明显变慢，或数据盘 IO 在结账窗口持续打满时（需实测确认） |
| 分机或分层 | 应用与数据库各一台，或附件目录放独立大容量存储；应用与数据库之间走内网互通，数据库不暴露公网 | 多分支机构、异地协同、期末报表复杂度高、或附件量已进入持续快速增长的阶段 | 多一台机器的管理成本与内网规划成本；跨机访问需要低延迟内网；备份与恢复演练要覆盖两台机器的一致性问题 | 已在同机分盘档位且结账窗口的资源争用无法通过错峰与索引优化缓解时 |
Dolibarr 官方把需要备份的内容明确分成三处：数据库、文档目录、以及配置文件 conf.php。数据库存的是界面上录入的业务数据，文档目录存的是上传的附件和系统生成的 PDF 与 ODT，配置文件存的是连接数据库的参数和文档目录的路径。官方给的频率建议是：数据库每月甚至每周备份一次（取决于使用强度），文档目录每半年或每月备份一次。这个建议背后有一个现实判断——官方自己也提到，完整复制整个文档目录可能是一个很重的过程，所以如果做不到频繁备份文档，至少要保证数据库有备份，因为数据库小得多，恢复之后大部分文档可以通过系统重新生成。这里要补一句工程上的提醒：这条建议成立的前提是"文档可以重新生成"，而上传的扫描件、盖章回传件是不能重新生成的，它们只存在于文档目录里。所以更稳妥的做法是把两类数据分开看待——数据库可以高频全量备份，附件目录走增量策略。备份方式上，官方明确建议不要依赖 phpMyAdmin 这类第三方工具生成备份 dump，理由是它可能不包含全部的 MySQL 选项与变更，只有 mysqldump 才能保证 dump 文件能在任意 MySQL 版本上恢复；同时也提醒过，开启压缩时部分主机上会出现备份不完整（缺表）的情况，所以要么不开压缩，要么检查 dump 文件结尾是否有完成标记。全量 dump 的实际耗时、文档目录全量复制的实际耗时，都必须在你的数据量上实测，不能按经验值排窗口。
备份做了不等于能恢复。ERP 的恢复演练至少要覆盖四件事：dump 文件能不能真的导入到一个空库里、导入之后的字符与数据是否完整、文档目录恢复之后的文件属主与权限是否与 Web 进程匹配、配置文件里的文档目录路径是否与恢复后的实际路径一致。这四件事里任何一件没验证过，真出事的时候都会在半夜暴露出来。演练建议按季度做，并且把耗时记下来——这个耗时就是你的真实恢复时间，它不是从备份软件里读出来的，是从演练里量出来的。版本升级的回退路径同理。官方宣称可以随时升级到最新版本而不丢失数据，但"能升级"不等于"能降级"：官方社区对降级问题的回答是，只能重装升级前做的备份，如果没做备份就没有办法降级。所以升级窗口的排法是：先在另一台机器或克隆出来的环境上跑一遍完整的"备份 - 升级 - 验证 - 回退"，把每一步的耗时记下来，再按这个耗时去申请生产环境的停机窗口。还有一层容易被忽略的前置依赖：升级 ERP 版本之前要先确认运行时的版本区间。以官方兼容表为例，不同版本对 PHP 与数据库的最低要求不同，如果当前 PHP 或数据库版本落在目标 ERP 版本的支持区间之外，就要先升运行时，这会把窗口再拉长一段，必须在计划里预留。
CPU：ERP 的常态开销不高，但 PDF 生成与报表查询是偏重单线程的工作，所以选型时不要只看总核数，要同时看单核性能。核数需要覆盖"月末窗口里同时跑的批量任务数"，这个数字要在你的环境里实测。内存：要分两块算，一块是 PHP-FPM 进程池占用，等于进程数乘以单进程内存；另一块是数据库缓冲池，希望常用的单据表与索引能留在里面。官方要求的 PHP 128 MB 内存上限是单个进程的限制值，不是整机内存的建议值，两者不要混淆。系统盘：程序文件本身不大（官方给的量级是 150 MByte），但要加上操作系统、Web 服务器、PHP、日志和临时文件，重点是不要把文档目录放在系统盘上，否则附件增长会直接把系统盘撑满。数据盘：按前面那条公式算出的三年容量再乘余量来定，并且优先选支持在线扩容的形态。IOPS 与吞吐：报表的大范围扫描吃的是顺序读吞吐，单据写入吃的是随机写，两者叠加在同一个盘上时是相加关系，这个值需要实测，不要照抄别人的规格。带宽：ERP 的页面流量本身不大，上行峰值出现在月末批量下载对账单和异地分支集中访问的时候，有分支机构或需要给客户发下载链接的场景，要按上行峰值估而不是按日均估。独立 IP：证书部署、对外访问、以及系统发出的邮件可信度都需要一个固定的、干净的地址，这一项在 ERP 上不是可选项。
从 ERP 的使用周期看，挑机房时值得重点问的四个问题，重要性都高于"CPU 是哪一代"。第一个是磁盘扩容是否可以在线完成：能不能在不重装系统、不迁移数据、不长时间停机的前提下把数据盘扩上去，这直接决定了三年后那次扩容是一次工单还是一次事故。第二个是快照能力：快照是整盘还是支持增量、能保留多久、能不能针对单块盘回滚，因为分区规划做得好不好，很大程度上要看快照的粒度能不能配合。第三个是备份的存放位置：快照和备份不能只留在本机的另一块盘上，需要有独立的备份空间或者异地的一份副本，否则机器层面的故障会同时带走生产数据和备份。第四个是节点的地理分布：用户和分支主要在国内就选国内节点，有跨境业务、海外分支或者需要给境外同事开放访问的场景，要考虑中国香港节点或海外节点，延迟体验与数据出境的合规要求都不一样，要分开评估。另外如果走到分机部署，机房要能提供应用与数据库之间的内网互通，并且数据库这一层不要有公网暴露面，这属于部署的基本安全前提。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
把 ERP 的年度成本拆开看，构成大致是计算资源（CPU 与内存）、数据盘容量、快照与备份空间、独立 IP、带宽这几项。有意思的是它们随时间的变化趋势完全不同：CPU 和内存的开销在三年里几乎是一条平线，因为用户数没变、常态负载没变；而数据盘容量、快照空间和备份空间是持续上升的，斜率由单据量和附件量决定。也就是说，第一年看起来合理的预算结构，到第三年会被磁盘和备份这两项拉变形。这个结构差异会直接影响选型决策——在 ERP 场景里，把预算优先投给"容量可弹性扩展"和"备份能力完善"的方案，比投给更高规格的 CPU 更划算。价格方面，各项的单价随节点、配置与带宽形态而异，没有可引用的统一公开价，一律需询价或以官网实时报价为准；在做预算的时候，建议把隐性成本也单独列一行：升级与回退演练需要的人天、扩容迁移可能产生的停机窗口成本、以及恢复演练的周期性投入，这几项通常不会出现在报价单上，但在 ERP 的生命周期里是真实发生的。
看的不只是人数，是附件的增长斜率。如果单据上几乎不附扫描件，只有系统生成的 PDF，数据库和文档目录的增长都相对可控，同机同盘也能撑一段时间。如果每单都要附盖章回传件或签收单扫描件，附件量的增长会远快于数据库，那么哪怕只有十个人使用，也建议从一开始就挂独立数据盘，因为后期迁移的代价远高于前期多挂一块盘的代价。判断依据是你自己算出来的三年容量，不是人数。
加内存能缓解一部分问题——缓冲池变大之后，热数据不容易被大扫描冲刷出去，索引页也更容易常驻。但如果慢的根因是查询条件没有合适的索引、或者分组排序的结果集超过了可分配的内存而要落临时表，那么加内存只是把阈值推后，数据量再涨一倍问题会原样回来。正确的顺序是先看执行计划与索引，再决定是否加资源。
不一定。分机解决了资源争用与独立扩容的问题，但引入了跨机访问延迟、内网规划、以及两台机器备份一致性的新成本。如果同机分盘之后，月末结账窗口的资源争用可以通过错峰执行报表、优化索引、给批量任务排时间来缓解，那么不急着分机。分机的触发条件是"争用已经影响到正常录单且无法通过调度与优化缓解"。
系统生成的 PDF 在业务上确实可以按需重新生成，理论上存在清理空间；但上传的扫描件、盖章件、签收单属于业务凭证，通常有留痕要求，不能按日志的方式定期删除，清理策略要先过业务和财务这一关。压缩方面，JPEG 和大多数 PDF 内嵌图像本身已是压缩格式，再做通用压缩收益很低，不要把它写进容量规划里。
官方给的是数据库每月甚至每周、文档目录每半年或每月的区间，具体取哪个值取决于你能接受丢失多少数据，以及一次全量备份在你的数据量上要跑多久——后者必须实测。可行的做法是数据库走高频全量（它的体积小、耗时可控），附件目录走增量，两者分别定频率，而不是用一个统一频率去套。
观察两个信号：一个是月末结账跑完报表之后，一线录单的响应时间明显变长且持续一段时间，说明缓冲池冲刷已经影响到了交易；另一个是数据盘的 IO 在结账窗口持续处于高位，且通过错峰、索引优化、批量任务改期都无法压下来。两个信号同时出现，就值得评估分机了。
第一，估容量时用单据量和附件量，不要用人数。人数在三年里基本不变，单据量与附件量会翻几倍；按人数买的机器，第一年一定显得过剩，第三年一定不够。
第二，附件目录从第一天就单独放。代价是前期多一块盘的预算，收益是把"程序"和"数据"两条增长曲线分开；反过来省下的这笔钱，会以停机迁移的形式在一年半后连本带利还回来。
第三，官方的最低要求只用来定下限。程序文件与初始数据库的量级说明 ERP 门槛低，不代表三年后还是这个量级；容量要按自己代入的公式算，官方没有给附件数字，因为那本来就该由使用者自己量。
第四，先优化再扩容，但扩容路径要提前铺好。报表慢先看执行计划与索引，这能省下一笔资源钱；同时磁盘是否支持在线扩容要在选型时就确认，因为等到满了再问，答案往往是要停机。
第五，备份的价值由演练决定，不由频率决定。高频但从未恢复过的备份，和没有备份在风险上差别不大；而演练记录下来的耗时，才是你能写进变更计划的真实恢复时间。
第六，升级前先跑一遍回退。能升级不等于能降级，没有备份的回退在官方口径里不可行；把"备份 - 升级 - 验证 - 回退"在克隆环境里完整走一遍并记下耗时，再决定生产窗口排多久。
本文只讨论开源 ERP（以 Dolibarr 这类 PHP + SQL 架构为代表）的负载形状、数据增长的估算方法、部署摆放方式与选型思路，包括稳态 OLTP 与期末高峰的负载特征、模块启用对写入路径的影响、附件目录的增长特性、报表与交易的资源争用、应用与数据库的三种摆放方式、备份与升级窗口的安排，以及 CPU、内存、系统盘、数据盘、IO、带宽与独立 IP 的配置决策。本文不比较任何具体 ERP 产品或服务商的优劣，不给出任何未经核实的并发数、容量或性能承诺，不指向任何具体客户，也不构成性能或可用性承诺。
文中引用的官方口径均来自 Dolibarr 官方 wiki 与官方站点公开页面，包括：程序文件约 150 MByte、初始数据库约 35 MByte、数据库规模约每 100 个客户/供应商/发票不足 1 MB、PHP 需允许 128 MB 内存上限、超过 30 用户建议 1GHz 以上 CPU、附件空间取决于上传文件的数量与大小；数据分数据库、文档目录、配置文件三处备份，官方建议数据库每月至每周、文档目录每半年至每月备份一次，建议用 mysqldump 而非第三方工具生成备份，启用压缩时需检查备份完整性；版本兼容表给出的 PHP 与数据库版本区间（如 24.0.0 为 PHP 7.2 至 8.5，MySQL 5.7.7+ 或 MariaDB 10.3+ 或 PostgreSQL 9.1.0+）；计划任务模块需每 5 分钟从外部触发一次；PDF 生成使用 PHP 的 PDF 库并写入文档目录。以上内容以官方最新文档为准，版本区间会随版本演进而变化，部署前请自行核对。
除此之外，文中所有涉及容量的数字——单据年增长量、单条记录占用字节、附件平均大小、全量备份耗时、文档目录复制耗时、报表执行时间、磁盘 IO 水位、带宽峰值——均需在自有的单据量与附件量下实测确定，本文不提供可套用的经验值。文中出现的场景描写为通用示例，用于说明负载形状与配置取舍，不指向任何具体客户或项目，也不构成对任何配置方案的性能或可用性承诺。价格相关表述一律为需询价或以官网实时报价为准。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
如果你正在为开源 ERP 选机器，建议先把三件事做完再谈配置：把要启用的模块清单定下来，把单据量与附件量代入公式算出三年容量，把期末结账那几天的报表清单和它们的执行耗时实测一遍。这三件事做完之后，CPU 该几核、数据盘该多大、要不要分机，答案会自己浮现出来。具体的机型、机柜、带宽与报价，仍要以官方实时信息或咨询确认为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
