选云服务器时，很多人先看的是价格和配置数字，比如4核8G、带宽5Mbps。可服务上线以后，网站卡不卡、接口慢不慢，跟这些数字的对应关系并没有那么直接。性能是几个部分一起作用的结果，计算、内存、存储和网络都要看。其中任何一项先撞到上限，整体体验都会跟着变差。
四类指标各自管什么
平时排查时，可以按下面四个方向逐项看。它们互相牵连，所以单看一项经常得不出结论。
- CPU：关注vCPU的主频、核数，以及实例是不是独占。这决定了单位时间能算多少东西。使用率不高也不代表没问题，要结合负载一起看。
- 内存：内存不够时，系统会开始使用交换分区，响应速度会明显下降。查看时重点看交换分区的使用量，只看总量意义不大。
- 磁盘IO：IOPS和吞吐量会影响数据库读写、日志写入和文件上传下载。如果业务有大量随机读写，这一项要放在最前面看。
- 网络：带宽上限、内网延迟和包转发能力，决定了并发访问和服务之间调用的效率。带宽标称值够用，不代表跨地域调用也够快。
一次大促前的排查经过
某中型电商团队在大促前一周做压测，商品详情页在并发300左右时，平均响应时间从200毫秒涨到了3秒以上。团队第一反应是代码有问题，但应用日志显示业务逻辑本身耗时并不高，说明问题可能出在别的地方。
运维同事登录服务器，用top和iostat查看了情况。CPU使用率只有40%左右，内存也还有余量，但磁盘IO等待时间很长，数据库所在云盘的IOPS已经顶到了上限。这台实例用的是普通云盘，IOPS上限固定，而商品库每次查询都会产生大量随机读。
团队做了两件事：把数据库迁到性能型云盘，并给热点商品数据加上Redis缓存。调整后，同样的压测条件下平均响应时间回落到250毫秒左右，CPU使用率也降到了合理区间。
这个例子说明，瓶颈经常不在你最先怀疑的地方。CPU看起来空闲，并不代表扩容一定有用。加核数之前，先查清楚是哪一项先到了极限，否则钱可能花得很冤。
用工具把性能量化
判断性能好不好，只靠感觉不够。更稳妥的做法是用基准测试工具得到可以对比的数字，再对照监控数据来分析。
- sysbench：测CPU计算能力和内存读写速度，适合在不同规格的实例之间横向对比。
- fio：模拟随机读写和顺序读写，能测出磁盘实际的IOPS和吞吐量。厂商标称值只能作参考，用fio跑出来的数字更有说服力。
- iperf3：测两台服务器之间的实际带宽和延迟，适合验证内网或跨地域链路的表现。
基准测试给出的是理想条件下的上限。真正能说明问题的，是用接近生产环境的请求模式去压测，然后观察业务指标怎么变化。比如接口成功率、P99响应时间这类数字，比单纯的跑分更贴近用户的实际感受。
突发性能实例要留意积分
不少云厂商提供突发性能型实例，价格比较低，平时CPU基线也低，遇到流量高峰时可以短时间爆发。它的代价是依赖CPU积分。如果服务长期处于高负载，积分耗尽后性能会被限制在基线水平。
有位开发者把定时数据同步任务放在这类实例上。前几天一切正常，第二周开始任务频繁超时。看监控才发现积分余额已经归零，CPU被限速。换成固定性能的通用型实例后，问题就消失了。
所以选突发型实例之前，先看看你的负载是不是持续高峰。如果是定时长任务或稳定的后台服务，固定性能的规格通常更省心。
选型和运维的几条建议
- 先按负载类型选规格：计算密集的服务优先看高主频机型，内存占用大的服务选大内存机型，数据库类服务重点看存储IO能力。
- 用真实流量验证：选型前用生产级的请求做压测。同样的规格，在自己的业务里表现可能和跑分差别很大。
- 盯住几个早期信号：CPU steal时间、磁盘IO等待、网络丢包和内存交换量，往往比总体使用率更早反映问题。把这几项放进监控面板，比等报警再去看要好。
- 提前留出扩容余量：业务增长时可以垂直升配，也可以增加实例做横向扩展。规划做在前面，比半夜临时救火省事得多。
写在最后
云服务器的性能很难用一个数字说清。弄清计算、内存、存储和网络各自的边界，再用测试和监控的真实数据做判断，才能在成本和体验之间找到比较合适的平衡。下次选型前，不妨先想一想：我的业务最先会卡在哪里？
