云主机迁到物理节点后，不能只凭核心数、内存容量判断资源是否匹配。硬件规格相近，实际表现仍可能受 CPU 频率、内存通道、磁盘队列、网络路径和资源争用影响。制定云主机迁移至物理节点的性能验收标准，应以原环境的实际负载为参照，重点核对吞吐、延迟、错误率和持续运行表现。
先确定对照条件，再测性能
迁移前后应尽量使用同一版本的应用、相同数据集、相同请求比例和相近并发量。测试时记录时段、持续时间、并发数及后台任务；避开一边空闲、一边处于业务高峰的误差。建议先做至少三轮短测，再在接近日常峰值的负载下持续运行。若业务有明显周期，应覆盖其繁忙时段。
将旧云主机的稳定运行数据作为基线，分别记录平均值与 P95、P99 延迟。平均值容易掩盖少量慢请求，尾部延迟更能反映高并发时的体验。可用性能基线统一整理原环境和新节点的结果。
五类指标要逐项核对
1. CPU：看持续吞吐和频率变化
用业务负载或同一基准测试比较单位时间完成的请求、任务数，以及 P95 延迟。若新节点吞吐低于基线约 10%，先检查 CPU 是否持续降频、是否有其他进程占用，以及任务是否跨 NUMA 节点访问内存。具体容忍幅度应按业务 SLA 设定；短时跑分高，不代表持续负载下也能维持。
2. 内存：看容量、带宽与交换活动
确认可用内存能容纳业务进程、缓存及操作系统开销，并观察高负载时是否出现频繁换页。需要比较计算密集型程序时，可用 STREAM 等工具观察内存带宽；不同处理器和内存配置的结果不可直接当作业务性能。容量足够但带宽不足，仍可能拖慢数据处理。
3. 存储：同时测吞吐、IOPS 和延迟
按业务的读写比例、块大小和并发队列测试，分别记录顺序吞吐、随机 IOPS、平均延迟及 P95 延迟。数据库、日志服务等随机读写较多的负载，不能只看大文件连续读写速度。测试数据应大于可用缓存，避免测到缓存命中而误判物理介质表现。
4. 网络：测双向吞吐与丢包
用 iperf3 在实际通信路径上分别测试收发方向，同时观察往返时延、丢包和连接重传。测试结果会受网卡速率、交换网络、虚拟化路径及并发流数量影响，因此应在与业务相同的网络位置进行；单机环回测试不能代表节点间通信质量。
5. 应用：以真实请求验证整体效果
最终对比请求吞吐、P95/P99 响应时间、超时与错误率。若底层指标看似合格但应用变慢，应检查线程数、连接池、缓存命中和磁盘等待等环节。应用层结果是判断资源是否匹配的最终依据，不能由单项跑分替代。
一套可执行的验收流程
- 留存基线：从原云主机记录 CPU、内存、磁盘、网络及应用指标，并标注负载条件。
- 统一环境：在物理节点部署相同应用版本与配置，确认数据集、测试路径和并发设置一致。
- 分项压测：先单独测计算、存储和网络，定位短板；再运行混合负载，观察资源竞争。
- 持续运行：在代表性负载下运行数小时；关键业务可安排更长观察窗口，检查降频、队列积压、温度告警和错误日志。
- 按约定判定：可将吞吐不低于基线的 90%、P95 延迟增幅不超过 10% 作为初始参考，但这只是常见的谈判起点，并非通用标准。应结合业务 SLA、测量波动和合同约定调整；错误率、超时及稳定性也必须达标。
用同一把尺子判断是否匹配
云主机迁移至物理节点的性能验收标准应同时覆盖资源能力与业务结果：配置确认资源上限，基准测试找出部件差异，真实负载验证最终体验。报告中保留测试条件、原始数据、差异比例和未通过项，才能明确是资源不足、配置不当，还是网络路径造成影响。只有关键业务指标达到事先约定的门槛，且持续运行没有异常，才适合确认资源匹配。
常见问题
只比较 CPU 核数可以吗？
不可以。核心数相同不代表单核性能、持续频率和内存访问能力相同，应结合业务吞吐与延迟验收。
迁移前没有性能基线怎么办？
先在原环境按实际高峰采集一段有代表性的指标；若已无法采集，可依据 SLA 设定目标，并明确这种验收缺少直接前后对照。
一次跑分通过就能验收吗？
不建议。至少复测并做持续负载检查，避免短时测试掩盖降频、资源争用或队列积压。
物理节点跑分更高，业务变慢是什么原因？
检查存储延迟、网络往返时间、应用配置及并发资源争用；综合业务指标定位，不能只依据 CPU 跑分下结论。