直接答案：先测一次业务请求消耗多少 CPU 时间，再按峰值请求率计算所需 CPU-seconds/s，并给发布、备份和抖动留余量。vCPU 数量只说明可调度并行度，不保证处理器代际、持续主频或共享宿主机资源相同；选择共享还是计算型，应以相同镜像、相同负载、相同时间段的 p95 延迟和 steal 数据决定。
本文于 2026 年 9 月按公开技术文档重新核对。文中的公式用于建立可复测预算，不是厂商性能或价格承诺；实例代际、线路、计费和功能会变化，最终应以当前产品页、合同、控制台和自己的原始测试为准。
先把问题变成一张证据表
| 对象/信号 | 含义或适用场景 | 应核对的证据 | 决策边界 |
|---|---|---|---|
| 持续 us 高 | 应用计算密集 | 先看热点函数和线程 | 优化后仍高再加核或用计算型 |
| sy 高 | 系统调用/网络/上下文切换 | 看包量、软中断、切换 | 加核前先修内核与网络瓶颈 |
| wa 高 | 在等磁盘 IO | 看 iostat 延迟和队列 | 换CPU通常无效 |
| st 高 | 虚拟机被宿主机抢占 | 跨时段连续采样 | 比较专用或更稳定实例 |
| CPU不高但延迟高 | 锁、外部接口或数据库 | 分解请求时间 | 不能凭低CPU继续降配 |
这张表的作用是把“感觉够用”“听说更快”改成可以复核的条件。同一规格在不同镜像、地区、底层代际和业务模型中可能得到不同结果。对比时必须固定应用版本、数据集、测试点和时间窗口；缺少这些条件的跑分或报价，只能当线索，不能直接用于采购。
核心计算与判断模型
最低 vCPU 估算 = 峰值每秒请求数 × 单请求平均 CPU 毫秒 ÷ 1000 ÷ 目标利用率。若峰值 40 req/s、每次消耗 25ms CPU、目标不超过 60%，计算值约 1.67 vCPU；实际还要覆盖后台任务、GC、数据库代理和故障余量。
计算后还要做反向校验：如果预算推导出的配置与真实监控差异很大，先检查单位、采样周期、缓存命中、突发任务和统计口径。不要为了让公式符合预期而删掉异常样本；异常样本往往正是容量、计费或故障风险所在。
建议同时保留“正常日、业务高峰、发布/备份日”三条基线。平均值用于成本预测，峰值和尾延迟用于稳定性判断，故障演练用于恢复能力判断。三类证据回答不同问题，不能互相替代。
可执行的六步流程
第1步：先留证据，再作决定
固定测试版本与数据集，用 pidstat、mpstat 和应用指标同时记录 user、system、iowait、steal、运行队列和单请求 CPU 时间；只看控制台平均值会掩盖一分钟尖峰。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第2步：先留证据，再作决定
把 Web、队列、计划任务、压缩、图片处理和数据库分开测。不同进程混在同一实例时，应分别记录峰值是否重叠，而不是把各自最大值机械相加。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第3步：先留证据，再作决定
做逐级并发测试，每级至少稳定数分钟，记录吞吐、p50/p95/p99、错误率和 CPU。吞吐不再增加而延迟陡升的位置，比‘跑满100%’更有选型价值。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第4步：先留证据，再作决定
在共享实例上连续观察 steal 与性能波动，至少覆盖业务晚高峰。若同负载下延迟周期性恶化且 steal 同步升高，才有证据评估更稳定的实例类型。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第5步：先留证据，再作决定
核数增加后检查应用是否真能并行：单线程程序、全局锁、数据库串行事务或单队列消费者可能无法利用额外 vCPU，先改并发模型比盲目升配更有效。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第6步：先留证据，再作决定
上线后把 CPU 类型、镜像版本、压测脚本、阈值和结果存档；版本发布或流量模型改变后重新测，不沿用几个月前的单请求成本。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
五个最容易造成误判的做法
- 用网站日PV直接换算vCPU
- 只看平均CPU而忽略一分钟峰值
- 把load average当CPU百分比
- 在不同地区或不同镜像上比较实例
- 压测时让缓存命中率与生产完全不同
这些做法共同的问题是缺少可比较条件。正确的纠偏方式不是再换一个“推荐配置”，而是把输入、阈值、失败现象和回滚条件写进记录。涉及删除数据、改防火墙、重装、扩缩容或切换 DNS 时，必须先有备份和可用的回滚入口。
上线、变更与回滚边界
先在隔离环境或小流量上验证，再逐步扩大。变更前保存配置、账单截图、监控基线和关键数据备份；变更中只改一个主要变量；变更后使用相同测试重跑。若核心业务写入失败、错误率持续上升、尾延迟越过停止阈值、数据校验不一致或管理员入口失效，应立即停止扩量并按预案回滚。
回滚不是简单恢复一个控制台选项。还要检查期间产生的新订单、表单、上传或数据库写入，明确如何合并，避免回到旧环境后丢失新数据。只读站与持续交易站的回滚难度完全不同，方案必须按业务写入特征设计。
验收清单
- [ ] 有单请求CPU时间
- [ ] 测试覆盖峰值并发
- [ ] 记录us/sy/wa/st
- [ ] p95和错误率满足目标
- [ ] 持续利用率保留余量
- [ ] 后台任务已计入
- [ ] 重启后服务能恢复
- [ ] 升降配有回滚窗口
至少跨过一次真实高峰或等价的受控测试，并由另一位维护者按记录复现关键结果。只完成“页面能打开”不算验收；必须能解释资源、网络、费用、恢复和安全边界。验收失败时，把具体指标和时间写入问题单，而不是用“偶尔慢”“可能线路问题”结束调查。
相关站内资料与产品入口
可结合CPU 100% 排查、监控告警指标、2核2G建站容量继续核对。需要建立隔离测试环境时，可查看美国轻量云和美国弹性云服务器的实时规格、库存及计费；本文不写死价格，也不把某个当前套餐描述成对所有业务都合适。
常见问题
2核一定比1核快一倍吗？
不一定。只有工作能并行、其他瓶颈不先出现且底层性能相近时，增加核心才可能接近线性提升。单线程、锁等待或磁盘瓶颈不会自动翻倍。
主频越高越好吗？
主频只是一个因素，还受架构、睿频持续性、缓存、内存、共享争用和编译方式影响。应以相同工作负载的完成时间和尾延迟比较。
CPU长期80%需要立刻扩容吗？
要同时看持续时间、运行队列、延迟、错误和增长趋势。稳定批处理可以接近高利用率；面向用户的请求服务通常需要给突发和故障留更大余量。
steal为0就说明宿主机没有争用吗？
它是重要线索但不是完整结论。采样粒度、虚拟化实现和其他资源争用都会影响表现，应结合相同负载的延迟波动判断。
数据库和网站能共用CPU吗？
小站可以，但要观察两者峰值是否重叠。数据库刷盘、备份和慢查询会与应用争抢CPU与IO，增长后应分别设预算或拆分。