iostat -x 1重点看%util、await、svctm若%util持续90%且await50ms磁盘成瓶颈SSD需结合r/s、w/s、吞吐量判断物理备份写NAS时await高多因网络延迟。备份时磁盘 I/O 突增iostat 怎么看关键指标MySQL 备份尤其是 mysqldump 或物理备份本质是大量顺序读 写I/O 压力会直接反映在磁盘设备上。iostat -x 1 是最直接的观察方式重点盯紧三列%util设备忙时占比、awaitI/O 平均等待毫秒、svctm实际服务时间已废弃但仍有参考价值。若 %util 持续 90% 且 await 50ms说明磁盘已成瓶颈不是 CPU 或内存的问题。iostat -x 1 中的设备名要对应真实备份目标盘如 sdb 而非 sda别只盯着 avg-cpu 部分物理备份写入 NAS 或远程挂载目录时await 高大概率是网络存储延迟iostat 显示的是本地块设备层可能掩盖真实瓶颈SSD 上 %util 接近 100% 不一定代表过载因并行能力强得结合 r/s、w/s 和吞吐量rkB/s/wkB/s综合判断top 里哪些进程真在拖慢备份top 默认按 CPU 排序但备份卡顿往往不是 CPU 吃满而是进程阻塞在 I/O。必须按 Shift F 进入字段选择再按 o 切换到 STATE状态排序或直接按 Shift R 反向排序后找 D 状态uninterruptible sleep进程——这类进程正在等磁盘响应正是你要揪出来的“真凶”。mysqldump 进程本身通常显示为 Ssleeping不占 CPU但它触发的内核 I/O 请求会让 mysqld 主进程或 pdflush旧内核/ ksmd 等后台线程变 D如果看到大量 rsync、gzip、pv 进程处于 Rrunning且 CPU 占用高说明压缩或传输环节成了新瓶颈和 MySQL 无关top 的 %CPU 列是采样周期内的平均值短时尖峰容易被平滑掉对瞬时 I/O 毛刺iotop -o只显示实际 I/O 进程比 top 更准备份脚本里嵌入监控避免“跑完才发现炸了”等手动敲命令看负载备份早就跑崩了。得在备份前/中加轻量级检查。比如用 timeout 5 iostat -x 1 2 | tail -1 提取最新一行解析 %util或用 pgrep -f mysqldump | xargs -r ps -o pid,comm,state,pcpu,pmem,vsz,rss,etime -p 抓当前状态。关键是别让监控本身加重负载——避免每秒跑 iostat间隔至少 3–5 秒。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。