Sdb为双盘raid1，使用raid卡为“LSI Logic / Symbios Logic SAS1068E”，无cache。近400的IOPS压力已经达到了硬件极限。而其它机器使用的raid卡是“LSI Logic / Symbios Logic MegaRAID SAS 1078”，有256MB cache，并未达到硬件瓶颈，解决办法是更换能提供更大IOPS的机器，比如最后我们换了一台带 PERC6/i 集成RAID控制器卡的机器。需要说明的是，raid信息是在raid卡和磁盘固件里面各存一份，磁盘上的raid信息和raid卡上面的信息格式要是匹配的，否则raid卡识别不了就需要格式化磁盘。
IOPS本质上取决于磁盘本身，但是又很多提升IOPS的方法，加硬件cache、采用RAID阵列是常用的办法。如果是DB那种IOPS很高的场景，现在流行用SSD来取代传统的机械硬盘。
不过前面也说了，我们从软硬件两方面着手的目的就是看能否分别寻求代价最小的解决方案：
知道硬件的原因了，我们可以尝试把读写操作移到另一块盘，然后再看看效果：
3、最后的话：另辟蹊径其实，除了用上述专业的工具定位这个问题外，我们可以直接利用进程状态来找到相关的进程。
我们知道进程有如下几种状态：
D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped, either by a job control signal or because it is being traced.
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its parent.
其中状态为 D 的一般就是由于 wait IO 而造成所谓的”非中断睡眠“，我们可以从这点入手然后一步步的定位问题：
# for x in `seq 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
D 248[jbd2/dm-0-8]
D 16528 bonnie++-n 0-u 0-r 239-s 478-f -b -d /tmp
----
D 22[kdmflush]
D 16528 bonnie++-n 0-u 0-r 239-s 478-f -b -d /tmp
----
# 或者：
# while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
TueAug2320:03:54 CLT 2011
root 3020.00.000? D May222:58 \_ [kdmflush]
root 3210.00.000? D May224:11 \_ [jbd2/dm-0-8]
TueAug2320:03:55 CLT 2011
TueAug2320:03:56 CLT 2011
# cat /proc/16528/io
rchar:48752567
wchar:549961789
syscr:5967
syscw:67138
read_bytes:49020928
write_bytes:549961728
cancelled_write_bytes:0
# lsof -p 16528
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bonnie++16528 root cwd DIR 252,04096130597/tmp
<truncated>