腾讯云服务器突发性能实例：CPU 积分耗尽后网站为什么突然变慢
下午两点四十，一个客户发来消息说官网又慢了，上午同一个页面打开是一秒二，现在要五秒。这套系统跑在腾讯云服务器突发性能实例上，CPU 使用率在监控里一直只有百分之二十几，资源看着很闲。我让他先把 CPU 积分余额的曲线调出来，答案在三十秒内就出现了：积分从早上九点开始一路下滑，两点出头贴着零走。
积分是预支的算力，不是免费的余量
突发性能型实例的定价逻辑建立在一个假设上：大部分时间里，这台机器用不满它的全部核。厂商按一个基准性能来卖，比如每个 vCPU 只保证基准百分比的处理能力，具体比例以实例规格说明为准。实际负载低于基准时，差额会以积分的形式攒起来；高于基准时，先花积分，积分够就让你跑满，积分花完就只能回到基准。
三个参数决定了这套机制的边界：基准性能百分比、积分累积速率、积分余额上限。累积速率和基准挂钩，基准越低，攒得越慢；余额上限决定了你能透支多久，通常按"满额能跑多少分钟满核"来表达，规格越大上限越高。这三个数字都在规格文档里，选型时如果只看核数和内存，等于只看了一半。
积分不是共享的，也不是无限展期的。它更像手机套餐里的结转流量：这个周期攒的，下个周期不一定还在，攒到上限就停止累积。所以"平时省着用、高峰一次放出来"这种想法，在积分上限面前不成立。
我在给客户解释时喜欢用信用卡的比喻：基准是月收入，积分是额度，刷卡的时候很爽，账单日在你不方便的时候到。区别在于，信用卡还能分期，CPU 积分花完就是硬降速，没有商量余地。
降频发生的那一刻，发生了什么
积分归零后，实例的 CPU 被限制在基准水平。限制的实现层次不在你的操作系统内核里，而在虚拟化或 cgroup 这一层，所以从实例内部看，现象是"进程在跑，但拿不到时间片"。
这时候 vmstat 1 里的 st（steal，被宿主机拿走的时间占比）会明显升高，r 列（运行队列）常年大于核数，而 us（用户态占比）反而不高。uptime 的 load average 会堆到核数的两三倍，看起来像一台被压垮的机器，实际上 CPU 有一大半时间不给你用。这三个信号同时出现，基本可以确定不是代码慢，是算力被限额了。
系统盘的 IO 也会跟着变差。CPU 被限之后，中断处理、软中断、文件系统日志提交这些内核工作同样抢不到时间片，表现出来就是磁盘 await 上升、网络收包延迟抖动。很多人一看 IO 慢就去查磁盘，方向从一开始就偏了。
还有一个连带效应：健康检查超时。负载均衡的探测请求本身很轻，但排在长队列后面，几秒才被调度到，探测判失败，流量被摘走，于是"机器没挂但服务不可用"。这类故障最难解释，因为监控上 CPU 没满、内存没满、磁盘没满。
三个症状，以及那个把问题盖住的平均值
第一个症状是上午正常、下午变慢。这是最典型的积分耗尽曲线：早上的业务量低于基准，积分缓慢上涨；十点以后并发上来，开始吃积分；到下午余额见底，性能断崖。曲线是渐进的，感受是突发的，所以业务方总说"突然就慢了"。
第二个症状是压测正常、线上慢。压测通常只跑五到十分钟，积分池足够撑完全程，P99 好看得很；线上是连续八小时的真实流量，中间还夹着定时任务和备份。用短压测得出的容量结论，放到长周期业务上几乎必然失真。
第三个症状是 CPU 使用率不高但响应慢。这是最容易误判的一种。使用率贴着基准线走，看起来还有富余，实际上每一毫秒都被精确限流，请求在队列里等着。看平均使用率永远看不出问题，因为限频的本质是"上限被改小了"，不是"用量变大了"。
我遇到过一家做企业官网加在线报名的客户，白天访问量不大，但每到下午做报名数据导出就整站卡顿。他们一开始怀疑数据库，加了索引、换了连接池，改善有限。真实原因是导出这种短时高 CPU 任务把积分一次性抽干，之后两三个小时的正常访问都在被限速。后来把导出挪到凌晨，并且给它单独限了并发，问题消失，一分钱没多花。
监控默认给你的是平均值，而且粒度常常是五分钟。五分钟均值会把三十秒的满核编译和四分半的空闲揉成一个"百分之二十"，看起来岁月静好。限频发生在毫秒级，均值和它根本不在一个时间尺度上。
第二个掩盖因素是采样口径。有的面板取的是 us + sy，有的取的是整机 CPU 总量，还有的按容器配额算百分比。同一个时刻，三个面板能给出三个数，你在群里对着不同的截图争论，问题还在那儿。
第三个是聚合维度。一台机器被限频，放到二十台的实例组里一平均，曲线平得像没事。等到一半机器都在被限，平均值才动，那时候业务已经抖了半小时。
我的做法是把三个东西画在一张图上：CPU 使用率的五分钟均值、CPU 积分余额、以及应用侧的 P99 响应时间。三条线的关系比任何单条线都有信息量：使用率不高、积分贴零、P99 抬升，指向限频；积分有余额、P99 还高，才需要往应用层查。粒度至少放到一分钟，能到十秒更好。
一条从积分余额开始的排查路径
第一步看余额，不看使用率。云监控里把实例的 CPU 积分相关指标拉出来，与使用率叠在同一时间轴上，确认两件事：有没有贴零的时段，贴零的时段和业务变慢的时段是否重合。重合就不用往下猜了。
第二步进机器看调度。vmstat 1 观察 st 和 r，cat /proc/stat 隔十秒取两次差值，自己算 steal 占比。如果 steal 稳定在两位数百分比，说明算力被别人拿走了，先确认是限频还是宿主机争抢。
第三步看限流计数。cat /sys/fs/cgroup/cpu.stat 里的 nr_throttled 和 throttled_usec，隔一分钟取两次，如果两个数都在涨，说明进程被 cgroup 反复掐断，这是限频最直接的证据，比任何推断都硬。
第四步排除应用侧。慢查询日志、连接池等待、GC 停顿、下游接口超时，这四项里任何一项都能单独造成变慢。判断方法很简单：把请求拆成段，看时间花在哪一段。如果时间花在"进入应用之前"，也就是排队和调度，那和 SQL 没关系。
第五步做对照实验。同一个镜像、同一个压测脚本、同样的并发梯度，分别跑在突发性能型和标准型上，对比 P99 和错误率。这个实验一次就能定性，比在群里讨论三天有用。
哪些业务不该省这份钱
编译构建、CI runner、爬虫、视频转码、批量图片处理，这些任务的共同特征是长时间吃满核，天然和积分机制冲突。省下来的机器钱，会以构建排队、任务超时、重跑的形式还回去。
持续高并发的 API 也不适合。它的 CPU 曲线是平的，一直贴着高位，没有"闲时攒积分"的阶段，等于从一开始就在透支。数据库更不用说，除了 CPU，还有 IOPS 和内存的硬要求，这类实例的规格通常不是为它设计的。
反过来，个人博客、展示型官网、企业内部管理后台、测试与预发环境、低频定时任务、轻量跳板机，这些负载有大量空闲时段，积分能攒得住，用突发性能型是合理的省钱方式。判断标准不是"业务重要不重要"，而是"CPU 曲线有没有明显的波谷"。
有一个前提要说清楚：波谷必须够长、够深，而且波峰不能持续。 一天里只有凌晨三小时空闲，白天八小时贴着高位跑，这种曲线用突发性能型就是在赌，赌的是白天不会来一波高峰。
迁移的三条路，各有各的代价
第一条是换标准型。CPU 全时段可以跑满，不用管积分，代价是同规格的价格上去了。适合波峰持续时间长、又不想改架构的业务。换的时候注意镜像和云盘可以保留，重建实例的停机时间取决于你有没有做镜像预热和弹性公网 IP 的解绑重绑。
第二条是换计算型。计算型的主频更高，单核性能更好，适合短请求、高并发、对单次响应时间敏感的服务，比如网关、游戏服、实时接口。核数不一定加，但每个请求跑得更快，总吞吐反而上去了。这条路的坑是"只看核数不看主频"，买了个大规格却发现单线程还是慢。
第三条是换轻量应用服务器。腾讯云服务器的产品线里，它是最容易被拿来和突发性能型做比较的一档。它的套餐把 CPU、内存、带宽打包，规格内 CPU 是固定保障的，没有积分这套机制，对单机站点和轻量 API 很友好。限制在于套餐档位固定、升降配不如 CVM 灵活，业务长起来之后迁移会有一次搬迁成本。轻量应用服务器的套餐细节以产品页当日公示为准，别按去年的印象选。
还有第零条路，不换机器：把定时任务挪到低谷、给导出类任务限并发、加一层缓存、把静态资源丢到对象存储加 CDN。我做过的案例里，有相当一部分"性能不够"其实是任务排布不合理，先优化再看要不要换规格，顺序别搞反。
它和竞价实例不是一回事
这两个产品经常被混着说，因为都属于"便宜的选项"，但控制的东西完全不同。竞价实例管的是计费和存活：机器可能因为市场价或者资源池紧张被回收，回收之后实例就没了。突发性能型管的是 CPU 上限：机器一直在，网络一直在，磁盘一直在，只是算力被压到基准。
风险形态也不一样。竞价的风险是"消失"，你要做的是检查点、幂等、优雅退出；突发性能型的风险是"变慢"，你要做的是容量规划、压测口径、任务排布。一个考的是中断恢复能力，一个考的是性能预算。
两者叠加时风险会相乘：机器既可能被回收，又可能在回收前已经被限频，你看到的是"任务跑了很久还没跑完，然后机器没了"。如果非要组合，至少保证任务能在限频状态下也推进，而不是靠满核才能在一个窗口内完成。
把这些类型放在一张表里，差异会更清楚。
实例类型 CPU 性能的保障方式 积分或额度机制 适合的负载 误用后的典型症状
突发性能型 基准性能加积分透支 低于基准累积、高于基准消耗，有余额上限 个人站、展示官网、测试环境、低频定时任务 下午变慢、使用率不高但 P99 抬升
标准型 全时段可跑满分配核数 无 常规在线业务、中小型数据库、稳定 API 成本偏高，但不会出现限频
计算型 高主频，单核性能优先 无 网关、游戏服、短请求高并发 核数买多了，单线程仍是瓶颈
轻量应用服务器套餐 套餐内 CPU 固定保障 无积分概念，按套餐规格供给 单机站点、轻量 API、开发测试 超出套餐带宽被限速，表现为下载慢
竞价实例 性能同标准型，但可能被回收 无积分，中断按回收规则 可重跑的离线任务、批处理 任务中途消失，不是变慢
FAQ
Q：CPU 积分用完了会怎样，会直接关机吗？
A：不会关机，也不会报错。实例继续运行，但 CPU 被限制在基准性能上，表现为请求排队、响应变慢、load 升高。等负载降下来、积分重新累积，性能会自己恢复。所以它经常被误判成"偶发的卡顿"，而不是资源不足。
Q：为什么压测跑得很漂亮，上线就慢？
A：压测的时间尺度太短。积分池撑得住十分钟的满核压测，撑不住八小时的真实业务，尤其是中间还夹着备份、导出、定时任务。要判断真实容量，压测至少覆盖一个完整的业务高峰，或者直接用积分余额曲线做推算。
Q：升级到更高规格的突发性能型，能解决问题吗？
A：只能缓解，不能根治。规格变大之后基准核数和积分上限都会提高，能透支的总量更多，但如果负载本身就是持续高位，更大的池子也只是把见底时间往后推。判断方法是看积分曲线：如果新规格下仍然贴零，问题在负载形态，不在规格大小。
Q：突发性能型和竞价实例可以一起用吗？
A：技术上可以，但不建议放在同一条关键链路上。竞价管存活、突发管性能，两个不确定性叠加之后，故障定位会变得非常困难。如果确实要组合，让竞价只跑可中断的离线任务，并且假设它随时处于被限频状态。
结语
预算卡到极致时，先看积分曲线再下单，这句话值一次返工。今天能做的三步：把现有腾讯云服务器突发性能实例的 CPU 使用率和积分余额画到同一张图上，标出贴零的时间段；拿真实的业务高峰曲线反推需要的基准核数，而不是拿平均值估；选型之前用同镜像做一次至少一小时的对照压测，看 P99 而不是看平均值。机器慢不一定是买小了，也可能是买错了类型，这两件事的解法完全不同。
如果需要更深入咨询了解可以联系全球代理上TG:jinniuge 他们在云平台领域有更专业的知识和建议，他们有国际阿里
3 .0
