一次AWS EBS磁盘IO利用率100%的真相

了一圈发现确实有一个日志备份(先压缩写入, 再读取通过网络传到S3上去)的 cronjob 正在执行。正当我以为是元凶时仔细一看这 job 的日志量不算大不至于把服务搞趴。但问题又确确实实发生了那个时间点也只有这一个明显的操作。好吧排障的经典套路来了先看基础设施层面有没有瓶颈。 常规指标一切正常登录监控系统Prometheus Grafana先扫了一眼传统三件套CPU不高才 20% 左右。内存也正常50% 左右。网络带宽用了 1Gbps 左右而 EC2 实例的基线带宽是 3Gbps离打满还远着呢。磁盘 IOPSEC2 跑的应用挂载的是 gp3 卷IOPS 基线 3000峰值可以飙到 12000 左右。当时的读写 IOPS 也就 500 多也没达到上限。这数据看着好像没什么问题……那应用为什么会慢等等。有个指标被我忽略了——磁盘 IO 利用率。注意Prometheus 中的node_disk_io_time_seconds或rate()化之后(具体是:instance_device:node_disk_io_time_seconds:rate5m)反映的是磁盘完成 IO 请求所花费的时间占比可以理解为磁盘的 忙碌程度。如果这个值维持在 100%说明磁盘一直是满负荷运转的IO 请求排着队应用能不卡吗。赶紧查了下这个指标好家伙直接 100%这就矛盾了明明 IOPS 和网络带宽都没打满为啥磁盘会一直 100% 忙 隐藏的凶手gp3 卷的吞吐量限制这时候我突然觉得不对劲仔细看了下网络流量和磁盘的指标。网络流量通过node_network_receive_bytes_total计算大约 1Gbps。磁盘吞吐量通过node_disk_bytes_total计算也是大约 1Gbps和网卡流量几乎完全吻合。等等gp3 卷的吞吐量上限是多少AWS 官网写得明明白白gp3 卷的吞吐量单独计价基础的吞吐量是 125 MB/s约 1 Gbps。不像 gp2, 如果你的 IOPS 和吞吐量都超出了基线可以利用积分burst credits但一旦积分耗尽吞吐量就会被硬性限制在 1 Gbps。gp3 卷的吞吐量上限默认就是 125 MB/s约 1 Gbps, burst 不了。除非你提前花钱买额外的吞吐量. 网卡流量 1 Gbps磁盘吞吐量 1Gbps这显然已经达到了 gp3 卷的 1Gbps 吞吐量限制。真相只有一个日志备份 job 产生了大量的磁盘写入/读取瞬间吃光了 gp3 卷的吞吐量积分导致后续所有的 IO 请求都被限速。应用发起的业务请求虽然 IOPS 不高但数据量不小也被堵在了队列里。磁盘 IO 利用率 100%并非 IOPS 不够而是吞吐量被卡住了。这就像是一个快递站gp3 卷的处理速度吞吐量是固定的突然来了一大卡车货日志备份把整条传送带占满了。后面来的一箱箱 VIP 快件业务请求只能等着自然就超时了。️ 如何确认这个猜想为了验证我快速查了以下信息对比网络入流量和磁盘写入量确认两者高度一致都达到了 1Gbps。这说明磁盘写入和网络流量是一路货。确认 gp3 卷的吞吐量配置检查控制台确认该卷的吞吐量配置确实是默认的 125MB/s1Gbps。 这次排查教会了我们什么️ 做得好的地方监控覆盖全面我们部署了 node_exporter采集了磁盘 IO 利用率、IOPS、网络带宽等几乎全部的关键指标没有出现盲区。常规指标都排查了第一时间排查了 CPU、内存、IOPS、带宽这是非常正确的第一反应。数据对比能力强能迅速对比网络流量和磁盘吞吐量发现两者数值吻合这是最关键的一步。 需要改进的地方对监控指标理解不够深只关注了 IOPS 和 带宽 是否打满而忽视了IO 利用率这个关键指标。它才是反映应用是否在排队等待 IO的望远镜。对 AWS 卷类型特性不熟虽然最后发现是 gp3 限速但排查过程中对 gp3/gp2 等不同卷类型的IOPS/吞吐量/积分机制缺乏系统了解。当时是 gp3真真切切被它坑了。 所以一个卷性能速查表是多么重要。排查流程不够完整排查时应该在常规指标正常后就立刻转向磁盘 IO 队列深度instance_device:node_disk_io_time_weighted_seconds:rate5m这是判断 IO 是否真的 拥堵 的核心指标而不是只看利用率。 写在最后一份实用的 EBS 性能排查清单这次 Case 让我意识到很多云原生 云计算的坑都是对底层基础设施的一知半解导致的。以后排查类似问题建议按以下顺序走看现象应用慢、超时。扫硬件CPU、内存、IOPS、带宽。⚠️ 如果这些指标都正常立刻进入第三步。看 IO 队列检查instance_device:node_disk_io_time_weighted_seconds:rate5m指标判断是否有 IO 拥堵。如果 IO 队列高但 IOPS 不高大概率是吞吐量或 IO 模型问题。对比流量查看网卡流量和磁盘写入/读取吞吐量看它们是否匹配。验证假设确认是 EBS 限速根据EBS类型判断是查BurstBalance指标, 还是查 IOPS 和 吞吐量等指标。确认是应用 IO 模型问题分析具体是哪个文件的读写导致 IO 高如/var/log的日志。调整配置EBS 限速升级卷类型如 gp3 → io2或调整吞吐量基线。应用问题优化日志输出如异步、批量、减少日志级别调整 cronjob 的执行周期或错峰, 日志备份限速等。对云服务的更多思考经历了这次问题, 我专门查找了相关的资料, 发现云服务的限制不止这些.云服务虽带来弹性与可扩展性但网络节流带宽限制常被忽视是导致应用响应慢、卡顿的重要原因。即便CPU、内存等指标正常网络节流仍会通过丢包、重传大幅增加延迟引发服务中断、性能不稳定甚至造成数百万美元收入损失。核心问题云服务商AWS、Azure、GCP等根据实例大小设定带宽基线超出后触发自动节流如AWS的突发积分耗尽后降速。节流规则复杂、不透明传统监控如仅测RTT无法有效识别NTP精度不足PTP成本高。常见场景与解决方案持续高利用率升级实例、负载分散、智能缓存。微突发Microburst应用级限速、流量整形、高粒度监控。未来应对策略实施实时单向延迟监控。架构设计考虑弹性容忍带宽限制。平衡实例大小与网络需求避免过度配置。建立性能基线主动测试。核心转变从反应式扩缩容转向主动自动化延迟自愈将网络节流管理视为业务必需而非仅IT问题。