mysql备份期间如何监控系统负载_使用iostat与top命令

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 秒。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。