突发性能实例的适用与坑

一台小机器平时运行正常，某天下午突然卡住，登录一看 CPU 利用率却只有百分之三十几。如果用的是突发性能实例，这个现象大概率是 CPU 积分耗尽了。 一、积分机制的原理 突发性能实例有一套积分系统：CPU 使用率低于基准线时攒积分，高于基准线时花积分。积分耗尽后，CPU 被强制限制在基准性能，比如基准 20% 的实例只能用到 20%。卡顿就这样发生，而且利用率数字看起来不高，很有迷惑性。积分按小时结算并设上限，不同规格的基准率和初始积分不同，购买页有明细。 二、怎么确认是积分问题 到云监控里找 CPU 积分余额曲线，积分清零的时间点和卡顿时间点对得上就是它。机器内部看不出来，因为限制发生在宿主机层面，应用自身毫无感知。这类实例适合负载有明显波峰波谷、平均利用率很低的场景：博客、文档站、测试机。 三、常见的坑 数据库跑在突发实例上是最常见的错误：数据库持续吃 CPU，积分长期入不敷出，等于一直用基准性能跑生产库。定时集中任务是另一个坑：每晚全量备份一跑半小时，把攒的积分一次花光，白天业务高峰反而没积分可用。开发机顺带跑构建任务也一样耗积分，低配突发机别当构建机用。 四、发现后的对策 把 CPU 利用率曲线调出来，对比实例的基准线：长期贴着或超过基准，说明该换通用型或独享型实例了。顺云的高防云服务器 S4、S4-8G 属于常规独享型配置，没有积分限制，业务要稳定运行靠的就是这种可预期。 突发实例是合法的省钱工具，但只适用于"大部分时间闲着"的负载。用错场景，省下的是小钱，赔上的是稳定性，遇到莫名的卡顿先查积分。拿不准自己用的是不是突发型，看规格名称里有没有"突发"字样或 t 前缀。