ERP 数据库服务器：内存优先，而不是 CPU 优先
一家电子厂的 ERP 在月底结账时卡到无法操作，原以为是 CPU 不够，实测是内存不足触发磁盘交换
内容说明：为避免泄露客户信息，本案例未标注企业名称、联系人与合同金额。行业、规模、配置与效果数据来自我方交付记录，用于说明选型思路，不构成对具体项目的效果承诺。
项目背景
这是一个典型的「凭感觉升级」场景。客户的判断依据是「人多用就卡，肯定是 CPU 算不过来」，于是准备买一台核数翻倍的机器。但 ERP 这类业务系统的负载特征很明确：并发用户数不高（这家厂约 60 个账号，峰值同时在线 25 人左右），SQL 查询的数据集不大（主库约 40GB），瓶颈通常出现在内存和磁盘 IO，而不是 CPU 算力。
我们在他现有服务器上装了 3 天的采样，覆盖一个完整的月底结账周期。数据很清楚：CPU 平均利用率 19%，峰值 46%；内存长期占用 96%，SQL Server 的 Page Life Expectancy（页面生命期望）掉到 30 秒以下（健康值应在 300 秒以上）；磁盘平均队列长度 3.8，结账时峰值超过 12。这三组数据指向同一个结论：内存不足导致 SQL Server 频繁从磁盘换页，换页又打满了本来就不快的机械盘。
所以方案的重点不是换更强的 CPU，而是把内存加到足以容纳整个工作集，再把存储从机械盘换成 SSD。CPU 只需保持在同一档位，把省下来的预算全部给内存和 SSD。
约束条件
选型不是「挑最好的」，而是在这些约束下找可行解：
- 切换只能在周末进行，周一早上必须能正常开机办公
- ERP 厂商只支持特定版本的 SQL Server 与 Windows Server，系统盘不能随意换版本
- 主库数据约 40GB，全量备份加日志必须能在 4 小时内完成
- 机柜是 12U 壁挂柜，深度只有 600mm，机型深度必须匹配
- 预算在 4 万以内，且需要保留原有数据盘用于回退
最终配置
下表为实际交付的配置与对应的选型理由，可对照自己的场景看哪些项需要调整。
| 部件 | 选型 | 选型理由 |
|---|---|---|
| 处理器 | 单路 16 核 32 线程（原 8 核） | CPU 不是瓶颈，但结账时的并行查询与报表计算确实受益于更多核数，适度提升即可 |
| 内存 | 128GB ECC（原 32GB） | SQL Server 的工作集约 70-90GB，128GB 可让热数据常驻内存，消除换页 |
| 系统盘 | 2 × 480GB 企业级 SSD，RAID 1 | 系统与 SQL 程序文件独立，避免与数据盘争 IO |
| 数据盘 | 4 × 1.92TB 企业级 SSD，RAID 10 | 数据库随机读写为主，SSD 的 IOPS 是机械盘的几十倍；RAID 10 写性能优于 RAID 5 |
| 阵列卡 | 硬件 RAID 卡，2GB 缓存带掉电保护 | 写缓存加速事务提交，掉电保护避免异常断电丢日志 |
| 网络 | 双口千兆 | 60 个客户端的内网访问，千兆足够，无需万兆 |
| 电源 | 550W 冗余电源（1+1） | 单机功耗实测约 210W，冗余电源保证单路故障不停机 |
| 形态 | 2U 机架式，深度 600mm 以内 | 匹配客户现有 600mm 深壁挂柜，避免设备装不进去 |
| 管理 | IPMI 带外管理口 | 周末远程装机与排障，不必到现场 |
被放弃的方案
比「选了什么」更有参考价值的是「为什么没选别的」。以下方案都曾进入备选：
核数翻倍的 CPU + 保持 32GB 内存
CPU 利用率仅 19%，加核数对换页问题毫无帮助，钱花在错误的部件上
加内存但保留机械盘
内存解决换页后，结账报表的全表扫描仍会压在机械盘上，改善有限
上全闪存阵列（独立存储）
40GB 的库用独立存储属于过度设计，预算会翻倍，运维也多一层
交付效果
| 指标 | 改造前 | 交付后 |
|---|---|---|
| 月底结账耗时 | 约 6 小时 | 约 40 分钟 |
| 白天查询响应 | 多人同时查询时 10-15 秒 | 2 秒以内 |
| SQL 页面生命期望 | 长期低于 30 秒 | 稳定在 2000 秒以上，基本无换页 |
| 磁盘队列长度 | 平均 3.8，峰值 12+ | 平均 0.2 以下 |
| 全量备份耗时 | 约 5 小时（常与结账抢 IO） | 约 25 分钟 |
交付过程
-
D+0
现场采集 CPU / 内存 / 磁盘队列 / SQL 等待类型，覆盖一个结账周期
-
D+3
出具采样报告，指出瓶颈为内存换页而非 CPU，给出配置建议
-
D+5
确认配置，与 ERP 厂商核对 SQL Server 版本与授权迁移方式
-
D+9
整机装配，安装同版本系统与数据库，做 3 轮恢复演练
-
D+11
周末切换：备份主库 → 恢复到新机 → 业务验证 → 切换连接串
-
D+13
周一早高峰观察，旧机保留 30 天可回退
复盘：三条可复用的判断
- 「卡」要先量化再归因。CPU 利用率、内存占用、磁盘队列三组数据一摆，方向就清楚了。
- SQL Server 的内存不是「够用就行」，而是要能装下整个热工作集，否则换页会吃掉所有性能提升。
- ERP 换服务器不是搬硬件，要和软件厂商确认版本、授权与迁移方式，否则周一开不了机。
同类项目的常见问题
多数中小企业的 ERP 场景应优先加内存。ERP 的并发用户数通常不高，CPU 利用率长期在 20%-40%，但数据库会把大量数据缓存到内存，内存不足会触发磁盘换页，性能断崖式下降。判断方法很简单：看内存占用是否长期高于 90%，以及 SQL Server 的页面生命期望是否低于 300 秒。
数据库以随机小 IO 为主，RAID 10 的写性能和重建速度都明显优于 RAID 5，代价是容量利用率只有 50%。如果预算允许、容量需求不极端，数据库盘优先 RAID 10；如果容量压力大，RAID 5 加 SSD 也能接受，但要配带掉电保护的阵列卡缓存。
标准做法是「备份—恢复—验证—切换」四步：先在旧机做全量备份并校验，恢复到新机，在新机上做业务验证（不只是能登录，要跑一遍结账报表），确认无误后再切换连接串。旧机不要立即格式化，保留至少 30 天作为回退。