磁盘是不是瓶颈？vmstat五个字段，比感觉靠谱

网站莫名变慢，CPU不高、内存也够，这时候嫌疑最大的就是磁盘IO。机械盘服务器上MySQL一忙，整站请求都在排队。vmstat一条命令就能把IO状况看得七七八八，成本几乎为零。

vmstat 1 10
# 每秒采样一次，共10次。重点看这几列：
# procs: r 运行队列（持续大于核数=CPU抢不过来）
# b 阻塞进程数（在等IO，持续高=磁盘瓶颈）
# memory: swpd 换出到交换分区的量（涨=内存吃紧）
# swap: si/so 每秒换入换出（非0=内存告急）
# io: bi/bo 每秒读/写块数（1块=512B）
# cpu: wa 等待IO的CPU时间（>10就该警惕）

诊断逻辑就三步。第一步看wa和b：wa持续两位数、阻塞进程一堆，磁盘就是瓶颈，没跑。第二步看bi/bo的方向：bi大是读密集（查询多、内存缓存没命中），bo大是写密集（ binlog、日志、频繁UPDATE）。第三步看si/so：换入换出非零说明内存先崩了，IO问题是内存问题的下游。

# 确认哪块盘忙：iostat看设备级数据（sysstat包）
iostat -x 1 5
# 关键列：
# %util 设备利用率，机械盘持续90%+基本打满
# await 每次IO平均耗时毫秒数，机械盘>10、SSD>2就不健康
# r/s w/s 每秒读写次数

找到瓶颈后的处理顺序，先软件后硬件。软件侧：MySQL的innodb_buffer_pool_size是不是给小了（数据在内存里反复读盘就是bi高的头号原因），日志类写入能不能挪走或降频，慢SQL里有没有全表扫描在狂读。硬件侧：机械盘换SSD是投入产出比最高的一次升级，比加CPU管用得多。

验证优化效果还是同一套命令：改完buffer pool或换盘后，vmstat 1再看，wa回落到个位数、bi明显下降，就说明药对症了。留一份优化前的输出存档，对比着看最有说服力。

说个真事：有站长的站每晚八点准时卡，top看CPU不高急得跳脚，vmstat一看wa飙到60，bo爆表——后来发现是个统计脚本每晚全表UPDATE。把脚本挪到凌晨、改成增量更新，问题没了。工具不会骗人，感觉会。

数据来源：Linux man-pages vmstat