磁盘 IO 高：%util 与 await 的解读

iostat 的输出有几十列，日常判断磁盘瓶颈，盯住 %util 和 await 两列就够了，其他列按需再看。 工具先备好 iostat 属于 sysstat 工具包，没装先补：yum install sysstat 或 apt install sysstat。常用姿势是 iostat -x 1 5，每秒采样一次共五次，几十列按表头对号，%util 在末尾，await 在中段。 两个指标什么意思 %util 是设备处理 IO 的时间占比，接近 100% 说明磁盘几乎没空闲——它只说明"忙"，不说明"慢"。await 是平均每次 IO 的等待时间（毫秒），才是体验指标：顺序写的 await 在几毫秒内算正常，冲到几十上百毫秒，业务就能感觉到卡。两列要合着看：await 高加 %util 高，瓶颈确认在盘；%util 高但 await 低，设备忙而不慢，未必是问题。顺手再看 avgqu-sz（平均队列长度），持续大于 2 说明请求在排队，与 await 相互印证；队列偶尔冲高而 await 平稳，是正常波动。 随机与顺序的差别 同样的数据量，随机小 IO 的开销远大于顺序大 IO。iostat -x 1 的输出里 r/s、w/s 很高而 rkB/s、wkB/s 不大，就是典型的随机小 IO，数据库类业务最常见的形态。确认来源用 pidstat -d 1 或 iotop，能看到哪个进程在读写，再回头看它的访问模式是查表还是写日志。 优化方向怎么排 按性价比排序：先降 IO 量——日志降频、合并小事务、加缓存层；再改 IO 模式——数据库日志与数据分盘存放，把随机写和顺序写拆开，互不排队；最后才是换更快的盘。顺序反过来，钱花了，随机小 IO 照样把新盘打满。分盘之外，把冷数据归档走也能给热盘减负，读写集中在小数据集上，随机 IO 自然变小。云盘还有一层性能基线机制：不少云盘按规格给固定 IOPS 基线，超出的部分靠突发额度，额度耗尽性能回落，表现为"没变忙却变卡"，iostat 只能看到 await 升高，根因在配额，对控制台监控的时间点就能确认。 提醒：判断 IO 问题要连续观察，iostat -x 60 配合监控趋势图看均值和峰值，比单次采样可靠得多。告警阈值按盘分别设，系统盘和数据盘的敏感度不同，混在一张图里容易被平均数骗。