碰到过好多次这种情况了，咱们先从你给出的iostat -ydx sdb 1数据里抓关键信息——你看w_await高达1734.67ms，aqu-sz（请求队列长度）也到了320.72，还有%util直接拉满100%，但每秒读写量其实不算高，这几个指标结合起来，大概率是下面这些原因导致的：

• 磁盘IO请求队列阻塞，单个请求处理时间过长
  你看svctm虽然显示6.33ms，但w_await（写请求平均等待+处理时间）却超过1.7秒，说明大量写请求在队列里排队等着。可能是磁盘本身性能瓶颈（比如机械盘遇到随机写，或者磁盘有坏道、老化），也可能是系统里有进程在发起大量小IO请求——比如很多小文件写入，或者数据库的随机写操作，单个IO虽然数据量小，但磁盘需要频繁寻道/寻址，把时间都耗在操作上了，导致队列堵满，利用率直接拉满，但总吞吐量上不去。

• IO调度策略不匹配
  如果你的服务器用的是机械硬盘，却用了noop这类更适合SSD的调度器，或者反过来SSD用了cfq，都会导致请求处理效率低下。比如机械盘用cfq时，如果有大量小随机写，调度器可能没法很好地合并请求，导致磁盘频繁切换读写位置，耗时增加，队列堆积，利用率拉满但吞吐量上不去。

• 磁盘缓存/刷写机制触发
  系统的页缓存（page cache）在积累到一定量时，会触发批量刷写（比如pdflush/kswapd这类进程）。如果此时刚好有业务的写请求，就会和缓存刷写的IO抢资源，导致请求排队，w_await飙升，利用率拉满。另外，如果开启了磁盘的写缓存，但突然触发断电保护机制强制刷写，也会出现这种短暂的高利用率低吞吐量情况。

• 进程IO优先级抢占
  系统里可能有高IO优先级的进程（比如备份进程、日志归档进程）在后台跑，它们会抢占磁盘IO资源，导致业务的写请求被挤到队列后面，等待时间变长，看起来就是业务写文件卡顿，但总吞吐量没上去——因为后台进程可能也是小IO或者低吞吐量但持续占着磁盘的操作。

给你几个排查方向：

• 用iotop实时监控进程IO情况，重点看DISK WRITE列的进程，排查是否有异常进程在发起大量小写请求；
• 检查磁盘调度策略：执行cat /sys/block/sdb/queue/scheduler，机械盘建议用deadline或cfq，SSD推荐noop或mq-deadline；
• 检查磁盘健康状态：用smartctl -a /dev/sdb查看是否存在坏道、温度过高、寿命耗尽等硬件问题；
• 监控系统缓存刷写情况：执行vmstat 1观察si/so（交换区读写）和bi/bo（块设备读写）指标，或者通过sysctl vm.dirty_ratio查看脏页阈值是否设置不合理。

备注：内容来源于stack exchange，提问作者ZeroRin