大半夜收到报警说应用卡成PPT，或者用户反馈网站转圈圈。很多人第一反应是登录服务器top一下，看看CPU爆没爆。但说实话，单看CPU经常看不出所以然——有时候CPU才30%，应用照样卡死。这时候别慌，把AWS的CloudWatch（监控服务）调出来，盯着下面三个指标，大概率能把问题揪出来。

第一个指标：CPU利用率（CPUUtilization）——先看是不是算力瓶颈

这个指标大家最熟悉，就是EC2这颗“大脑”忙不忙。如果长时间高于80%，说明实例规格偏小，处理不过来。如果只是偶尔飙高，属于正常波动。

但有个情况值得留意：CPU不高，服务却响应慢。这时候就说明问题大概率不在算力，得往下看。

第二个指标：IO等待时间（EBS IOPS / 吞吐量）——硬盘拖后腿了

这个坑很多人都踩过。应用读写频繁，但EBS卷的IOPS（每秒读写次数）买低了，磁盘成了瓶颈。表现就是应用响应慢，但CPU并不高——因为CPU大部分时间在等磁盘把数据吐出来。

去CloudWatch里看EBS的VolumeReadOps / VolumeWriteOps和VolumeThroughput（吞吐量）。如果这两个指标持续跑满你购买的上限，那就是磁盘不够快。解决办法：把gp2换成gp3，或者提高预置的IOPS值。gp3本身比gp2便宜，性能还更好，是个性价比很高的升级。

第三个指标：可用内存（Memory Utilization）——别让系统开始“用虚拟内存”

EC2默认不带内存监控，得自己装CloudWatch Agent（代理程序）才能把内存数据推到CloudWatch里。如果没装，可以登进服务器用free -h看一下。

内存满了有什么后果？系统会把部分数据挪到硬盘上充当“虚拟内存”，速度瞬间掉几个数量级。应用跑得跟蜗牛一样，但CPU依然不高——因为它也在等内存交换完成。

解决办法很直接：升级实例规格到内存优化型，或者排查应用是不是有内存泄露。

万一是网络带宽满了呢？

附带提一个：NetworkOut（出站带宽）。如果应用对外提供文件下载或流媒体服务，带宽被打满，用户请求排队处理，响应自然就慢了。EC2的带宽规格和实例类型绑定，没法单独升级，只能换更大的机型。

怎么看这些数据？

去CloudWatch的“指标”页面，选你的EC2实例命名空间，勾上CPUUtilization、NetworkIn、NetworkOut。内存数据如果装了Agent，会在“CWAgent”命名空间里。

不会看也没关系，AWS控制台有“监控”选项卡，默认展示最近几小时的CPU和网络图表。内存的话要么装Agent，要么用SSH进去看一眼。

如果以上都正常，再看一眼数据库和代码

三指标都正常，服务还是卡？那问题可能出在数据库这边：RDS的CPU飙高、慢查询堆积、连接池占满，都会拖垮整个应用。去查RDS的CPUUtilization和DatabaseConnections（数据库连接数）这两个指标。

再不然，就是应用代码里有阻塞操作，比如同步调用外部API，或者死锁。这时候得配合应用日志和链路追踪工具来定位了。