我一直以为云盘标称的那个 IOPS 数字是恒定的，直到去年十一月那个周一早上。我们的订单库写入从平均 8 毫秒突然涨到 120 毫秒，队列一排就是几百个请求，CPU 却只有 5%。第一反应还是数据库，后来把连接池、慢查询、锁全排了一遍，什么都没查到。真正的问题是在 fio 测试里露出来的：写延迟从 0.4 毫秒跳到 30 多毫秒，而 iostat 里的 w_await 一直在往上走。
如果你正在处理云盘性能、IOPS 掉速这类具体问题，或者需要一台配置合适的机器先把环境跑起来，可以先看看这几家的报价和技术说明：浪浪云（全球云服务器 / 高性能服务器），以及 CubeCloud（全球云服务器 / 企业上云方案），下单前记得把 IOPS 规格和基线性能问清楚。
云盘的性能参数一般会写成两个数：一个是“最大 IOPS”，一个是“基线 IOPS”，或者写成“突发性能 X GB”。前者是你短时间能冲到的上限，后者是长期能保住的保底值。这两个数之间的差值，靠一种叫“突发性能积分（burst credits）”的机制兑现。
积分的逻辑很像手机流量套餐。买盘的时候给你一次性灌满积分，比如 100G 的突发积分，每写入 1GB 数据就扣掉 1GB 积分，扣完了这块盘就只能按基线 IOPS 跑。积分用光之后不会报错，也不会提示，只会让你的写入悄悄变慢。所以「8000 IOPS 的云盘」这句话本身是不完整的，它没告诉你 8000 能维持多久、维持不了之后会掉到多少。
第一步是排除数据库。慢的时候抓一份 processlist，执行的全是同一类 INSERT，没有锁等待，没有大事务，binlog 也没堆积。数据库慢查询日志是空的，说明 SQL 本身没问题，那问题就在更下面一层。
第二步看系统层面的队列。vmstat 里 b 列（阻塞在 IO 的进程）常年挂着十几个，wa 列，也就是 IO 等待占 CPU 的比例，一度到了 40%。这基本可以确认是存储。
第三步跑 fio。我用的是 4K 随机写、队列深度 32、单线程，先测 60 秒。结果第一轮跑出来 IOPS 只有 187，lat 30 毫秒上下，而同一个盘在刚开通那会儿，同样命令跑出来是 7600 IOPS，lat 0.5 毫秒。同一块盘、同一台机器、同一份脚本，差了四十倍。
第四步看控制台。存储用量那一栏有个「突发积分」的进度条，显示已经用尽，可用量为 0。这时候答案就出来了：不是磁盘坏了，是这块盘按设计降到了基线性能，我们的基线是 100 IOPS。
信号一，写放大比异常。我们那台机器每天的写入量大概是数据量的 8 倍，典型的写入密集型负载。而这块盘 100G 的突发积分，按每 GB 扣 1G 的算法，撑死撑一天半。这个账我当时没算，现在回头看是最大的失职。
信号二，fio 测速的时间点。新盘开出来第一次测，测出来的数字是最好看的，因为积分是满的。很多人（包括当时的我）就是拿这个数字当基线做容量规划的，等真掉速了才意识到那个数字本来就是「峰值」不是「常态」。
信号三，备份和快照会额外吃积分。云盘做快照、或者备份任务往数据盘上写数据，同样计入突发积分的消耗。我们的备份任务是每小时一次全量，一周下来额外扣掉不少，相当于自己给自己加了一道限速。
买之前先把三件事问清楚：基线 IOPS 是多少，突发积分有多少，积分多久重置一次（常见的是每天重置或者按月重置）。如果商家只给一个 IOPS 数字，那基本可以理解为基线性能被藏起来了。
然后按自己的写入量反推需要的积分。很多云盘按「每 GB 数据扣 1GB 积分」来算，你每天写入 2TB，那至少要有 2TB 的突发积分额度才够撑一天；如果峰值集中在两三个小时内，就得按峰值时段算，不能按日均值算。
再就是别指望调优能救。IOPS 掉到基线是云盘层面的限速，不是内核参数或者文件系统的问题。我试过调整队列深度、改 noatime、把 binlog 拆成独立盘，效果最多百分之几，量级上完全没意义。真要扛住，最直接的办法就是换一块基线 IOPS 更高的盘，或者把写入量本身降下来。
如果暂时没法换盘，短期有两个办法：一是把写入压力削峰，用队列把写入摊到积分重置之前完成；二是把最吃 IOPS 的那部分数据挪到本地 NVMe 或者独立的性能盘上，让系统盘只做低频的顺序读写。
这次故障前后折腾了将近两天，服务器商家的支持只回了一句「突发积分耗尽属于正常设计」，我们自己没提前算账，这是根本原因。写这篇不是想说云盘性能不靠谱，恰恰相反，它的限速逻辑其实很清晰，甚至有点耿直它就是明明白白告诉你，你的额度用完了，剩下的按合同来。反而是那些把峰值当常量的宣传话术，容易让人掉坑里。
如果你也在挑存储规格，记得先问基线，再谈峰值。顺序上别搞反了，不然就会像我一样，买盘时爽歪歪，用到一半才发现自己在为「峰值时刻」付全款。
