w命令不能识别IO负载，因其load average仅统计“运行中+等待I/O”的进程总数，不区分CPU-bound或I/O-bound；需结合vmstat（看b、wa）、pidof+/proc/PID/io、lsof等命令交叉验证才能准确定位IO瓶颈。
为什么 w 本身不能识别 IO 负载
w 命令输出的 load average 是系统整体负载，它包含「正在运行」和「等待 I/O」的进程数总和，但不区分 CPU-bound 还是 I/O-bound。也就是说，w 显示的 0.85, 1.20, 1.45 看不出有多少是磁盘卡住导致的——它只告诉你“有约1.4个任务在争抢资源”，至于争的是 CPU 时间片，还是在等 read() 从 SSD 返回数据，w 不提供线索。
从 w 的输出里找 I/O 相关线索的实操办法
虽然 w 不直接标出 I/O，但结合字段观察 + 快速交叉验证，能快速圈定可疑用户：
-
IDLE值极小（比如0.00s）但WHAT显示的是rsync、tar、dd、mysql或pg_dump—— 这类命令大概率在做大量读写，值得盯住 -
JCPU和PCPU都很低（如0.01s），但用户持续在线且IDLE几乎为 0，说明进程可能卡在系统调用上，常见于慢盘sync()、NFS hang、或数据库刷 checkpoint - 用
w -h | awk '{print $1,$9}' | grep -v '^$'提取所有用户当前命令，再筛出含io、disk、wait、copy的行（注意：这只是启发式排查，不是精确判断）
必须搭配的三个命令才能确认 I/O 负载来源
单靠 w 下结论容易误判。以下组合才是闭环验证：
- 跑
vmstat 1 3，重点看b（等待资源的进程数）和wa（I/O wait 占 CPU 百分比）：若b > 0且wa > 20%，基本可断定 I/O 是瓶颈 - 用
pidof -x <em>可疑命令名</em>拿到 PID，再执行cat /proc/<em>PID</em>/io | grep -E "(read_bytes|write_bytes|syscw)"，看实际 IO 量是否突增 - 对用户终端 TTY（如
pts/2）执行lsof -t -a -U -p $(ps -t pts/2 -o pid= 2>/dev/null | head -n1)，查该会话下是否有异常打开的大文件或阻塞 socket
一个典型误判场景：负载高但不是 IO 导致
比如 w 显示 load average 是 4.2，你发现用户正在跑 find / -name "*.log"，第一反应是“IO 太猛”。但实际 vmstat 显示 wa=0.3%、b=0，而 top 里 %CPU 接近 100% —— 这其实是 CPU 密集型遍历，find 在反复做路径解析和字符串匹配，并非磁盘慢。这时候盯 iotop 或 iostat -x 1 就会发现 %util 始终低于 10%。
真正需要警惕的，是 w 里某个用户 IDLE 为 0.00s、WHAT 是 cp /mnt/nfs/bigfile.zip /tmp/，同时 vmstat 的 bi（blocks in）持续大于 5000、wa 超过 40% —— 这才指向 NFS 服务器响应延迟或本地磁盘队列堆积。
