iostat -x 1重点看%util、await、svctm：若%util持续>90%且await>50ms，磁盘成瓶颈；SSD需结合r/s、w/s、吞吐量判断；物理备份写NAS时await高多因网络延迟。
备份时磁盘 I/O 突增，iostat 怎么看关键指标
MySQL 备份（尤其是 mysqldump 或物理备份）本质是大量顺序读 + 写，I/O 压力会直接反映在磁盘设备上。iostat -x 1 是最直接的观察方式，重点盯紧三列：%util（设备忙时占比）、await（I/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进程本身通常显示为S（sleeping），不占 CPU，但它触发的内核 I/O 请求会让mysqld主进程或pdflush（旧内核）/ksmd等后台线程变D - 如果看到大量
rsync、gzip、pv进程处于R（running）且 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 秒。
- 不要在
mysqldump命令前后各跑一次iostat就以为“覆盖全程”，中间的峰值完全可能漏掉 - 用
nohup iostat -x 1 > /tmp/iostat.log 2>&1 &后台持续采集，备份结束再kill，比临时抓更可靠 - 监控阈值要按机器调：机械盘
%util > 85%就该预警，NVMe 盘可放宽到95%，但await > 10ms就值得查
为什么 top 和 iostat 数据对不上
常见现象：iostat 显示 sdb %util 98%，top 却看不到任何进程占 CPU 或磁盘 —— 因为 %util 是设备驱动层统计，而 top 显示的是进程调度层视角。当 I/O 请求在队列积压、设备忙于处理但进程早已返回睡眠，top 就“看不见”负载来源。
- 这种错位在高并发小 I/O（如 binlog 写入 + 备份同时发生）时尤其明显，
iostat的avgqu-sz（平均队列长度）比%util更能说明问题 -
cat /proc/diskstats可以验证：对比iostat输出的读写次数与该文件中对应设备的字段，若差异大，说明有内核模块（如 device-mapper）或容器卷抽象层在中间劫持了 I/O - 使用 LVM 或加密卷（
dm-0）时，iostat默认不显示这些逻辑设备，需加-d参数才能看到真实后端设备负载
真正麻烦的是那种 iostat 看着正常、top 也风平浪静，但备份就是慢得离谱的情况——这时候得怀疑是不是 innodb_buffer_pool_size 设置太小，导致频繁刷脏页干扰备份读取，或者备份目标路径用了 noatime 以外的挂载选项，每次写都触发元数据更新。
