iotop -oP 能精准聚焦活跃的进程级I/O：-o过滤空闲进程（如idle php-fpm子进程），-P切换为进程视图（非线程），避免干扰，便于快速定位高磁盘写入的服务。
iotop -oP 为什么必须加这两个参数
不加 -o，iotop 会把所有进程（包括空闲的 php-fpm 子进程、nginx worker）全列出来，刷屏干扰大；不加 -P，它默认显示线程级 IO，但你真正要找的是“哪个服务在狂写”，不是它底下的某个线程。加了 -oP 才能只看正在干实事的进程，且按 DISK WRITE 降序排好——一眼就能揪出 mysqld、bt_backup 或某个 Python 脚本。
常见误操作：
• 直接敲 iotop 回车，结果满屏 idle 进程，浪费两分钟
• 用 sudo iotop -p [PID] 却忘了先确认 PID 是否真在写——得先 iotop -oP 看清谁在动，再针对性查
看到高 WRITE 进程后，lsof -p 怎么筛关键文件
lsof -p [PID] 输出可能上百行，重点只盯三类路径和标志：
- /www/wwwlogs/：如果看到几十个
REG类型 +W标志（比如/www/wwwlogs/site1.error.log），基本是日志没轮转或开了error_log /path error debug级别 - /www/server/panel/logs/：面板自身日志刷爆，常见于插件异常反复报错
- /tmp/ 或 /dev/shm/：前者可能是未清理的临时 dump 文件，后者说明用了内存映射 IO，得配合
strace -p [PID]看系统调用
安全红线：
• 别直接 rm -f 正被写的日志，用 echo "" > /www/wwwlogs/xxx.log 更稳妥
• 如果 lsof 里出现 /proc/[PID]/fd/123 这种数字路径，说明文件描述符已关闭但句柄还在，得查父进程是否泄漏
iostat -x 1 的 %util 和 await 怎么交叉验证
%util 高但 await 低（比如 %util=98、await=5ms）：大概率是大块顺序写（如备份 tar），磁盘吞吐跑满了但响应快，问题在带宽而非延迟。%util 中等但 await 飙高（比如 %util=60、await=1200ms）：典型小文件随机写，SSD 上尤其明显——队列深度大导致 %util 没拉满，但请求排队严重。
实操建议：
• 优先看 await，超过 100ms 就该干预，别等 %util 到 95%
• 用 iostat -d -x -k 2 替代 iostat -x 1，避免单次采样抖动误判
• 注意设备名：云服务器常见是 /dev/vda1，但日志可能落在独立挂载的 /dev/vdb1，得先 lsblk 确认主分区
查到 rsync 或 cp 进程要不要立刻 kill
先执行 ps -fp [PID] 看完整命令行：
• 如果是 /bin/bash /www/server/panel/script/backup.sh，那是宝塔自动备份，得去【计划任务】里关掉或限速
• 如果是 rsync -avz /data/ user@10.0.0.1:/backup/，确认是不是你手动触发的合法同步
• 如果是 find / -name "*.log" -exec cp {} /tmp/ \; 这种野路子脚本，果断 kill -15 [PID]
陷阱提醒：
• kill -9 可能中断写一半的文件，尤其对数据库 ib_logfile 类文件危险
• 宝塔的 bt_backup 默认不限速，后台跑起来能吃满 IO，但它不会在任务列表里显示为“备份”，而是一串 python 进程
