选择境外主机时，CPU 和内存不能只看配置表上的数字：相同的 vCPU 数量，在不同主机环境中的持续性能可能不同；内存不足则可能触发交换空间或进程被系统终止。做好境外主机CPU与内存规格的压测选型，关键是用接近实际的负载测试，并观察资源瓶颈出现在哪里。以下五步适用于网站、应用服务、数据处理等不同场景。
第一步：先描述真实负载
列出服务运行时的主要任务、并发量和高峰时段。记录平时与峰值的请求数、后台任务数量、进程或线程数，以及是否会集中处理图片、压缩文件或批量数据。若尚无线上数据，可先从预计并发和典型任务建立测试场景，再用后续监控修正。
区分持续负载和短时突发：持续负载关系到长时间运行的能力，突发负载则检验短时余量。只用空闲时的平均占用做选型，容易低估高峰需求。
第二步：记录空载基线与主机条件
测试前记录操作系统、CPU 型号或虚拟 CPU 数、内存容量、磁盘类型，并确认主机是否与其他租户共享资源。运行服务但不施加压力，观察一段稳定时段内的 CPU 使用率、内存占用、磁盘活动和响应时间，作为对照。
境外主机还要把网络因素单独记录：客户端所在区域、往返时延和丢包情况会影响请求响应时间，但不能直接说明 CPU 不够。最好从固定地点发起测试；遇到响应变慢时，同时查看服务器资源，避免把网络延迟当成计算瓶颈。
第三步：分项测试 CPU 和内存
先测 CPU 持续处理能力
可用 sysbench 或 stress-ng 施加可控的计算负载，逐步增加工作线程，并观察 CPU 使用率、处理吞吐量和任务耗时。若 CPU 长时间接近满载、吞吐增长停滞而耗时上升，说明计算能力可能不足。云主机还应关注CPU steal：该指标持续偏高，可能意味着宿主机资源竞争，单纯增加应用线程不一定有帮助。
再测内存峰值与稳定性
使用与实际服务相近的进程和数据量逐步增加负载，同时记录可用内存、交换空间使用和是否出现进程被终止。Linux 可查看系统内存统计及内核日志；重点不是追求“内存占用越高越好”，而是确认高峰时仍有余量，且没有持续交换或内存耗尽现象。
第四步：按五个可执行步骤完成压测
- 准备：选择与线上相同或相近的软件版本、数据集和配置，确认有停止测试的办法；避免在未获许可的第三方服务上发压测流量。
- 记录基线：在无压测的情况下保存 CPU、内存、磁盘、网络和响应时间数据。
- 逐级加压：从低并发开始，每档稳定运行约 5 至 10 分钟，再逐档提高；具体时长应根据任务启动和数据处理周期调整。
- 模拟高峰：按预估峰值运行，并安排一段持续测试，观察资源是否随时间累积、吞吐是否下降。需要验证突发能力时，另做短时高并发测试。
- 对照复测：分别增加 vCPU 或内存后，用相同条件重测，比较吞吐、耗时、交换空间和稳定性，不要同时改动多个关键变量。
第五步：依据瓶颈选规格并留余量
| 测试表现 | 优先考虑 | 适用判断 |
|---|---|---|
| CPU 持续繁忙，计算吞吐受限 | 更多或性能更稳定的 vCPU | 增加 CPU 后，任务耗时确有改善 |
| 可用内存持续偏低，出现交换或进程终止 | 更大内存 | 增加内存能消除内存压力，服务配置不变 |
| CPU 与内存都不紧张，响应仍慢 | 先查网络、磁盘或应用等待 | 资源升级未必解决问题 |
选择 CPU 时，优先比较目标工作负载下的实际吞吐和稳定性，而不只比较 vCPU 数量。选择内存时，应把操作系统、服务进程、缓存及高峰任务所需空间一并计入。可以先以实测峰值为依据，再为增长和波动留出约 20% 至 30% 的余量；这只是常见规划起点，缓存策略、并发变化和主机共享状况都会影响实际需求。完成境外主机CPU与内存规格的压测选型后，还应在流量或任务量改变时复测，而不是把一次测试结果当作长期保证。
常见问题
压测时 CPU 使用率达到 100%，就一定要升级吗？
不一定。若负载只是短时突发且响应正常，未必需要升级；若持续满载、吞吐停滞或耗时明显增加，再比较增加 vCPU 后的结果。
内存要预留多少才合适？
没有适用于所有服务的固定比例。可从实测峰值出发，先预留约 20% 至 30% 作为规划参考，再结合缓存、并发及业务增长调整。
为什么压测结果每次不同？
共享主机的邻居负载、客户端网络、后台任务和数据冷热状态都可能造成波动。尽量固定测试条件，分时段重复测试，并比较稳定区间而非单次峰值。
最后，境外主机CPU与内存规格的压测选型应围绕可复现的真实负载：先定位瓶颈，再逐项调整配置，并用相同场景验证升级效果。
