刚发现io写效率低是在业务写的同时手工进行一个大文件的io写，业务写被完全阻塞，同时服务器负载曾一度高至50左右（负载最高时cp
系统环境：centos release 5.10
应用环境：oracle 10.2.0.5 + php5.2.17
硬    件  ：dell r720，1t*3 7200r，raid5
业务环境：每5分钟sqlload入库5分钟内有效数据，数据大小30m左右
问题原由：
最近做了一次数据迁移，硬件由之前的300g*3 7200r变为1t*3 7200r并硬件raid5，其他环境对等迁移，但是迁移过后，感觉io写的效率极低，开始分析io是否存在瓶颈。
分析过程：
刚发现io写效率低是在业务写的同时手工进行一个大文件的io写，业务写被完全阻塞，同时服务器负载曾一度高至50左右（负载最高时cpu wait 45%左右，iowait 35%左右），看到这个负载，立马在oracle里面跑了一下相关sql【select * from v$locked_objects;select * from v$lock where request 0 or block 0;】，没有产生锁阻塞，还是觉得跑下awr，对比一下迁移之前和迁移之后做个对比吧，结果跑完之后，挺让人惊讶的（结果有一部分原因也算有点情理之中）
awr信息：2：00-3：00，纯业务，无其他操作，业务操作量相同，oracle配置完全相同（除redolog路径）：
179数据库（迁移前）：
top 5 timed events
eventwaitstime(s)avg wait(ms)% total call timewait class
cpu time 348 95.6 
log file sync12,7061213.3commit
log file parallel write13,5311213.2system i/o
enq: tm - contention492,3622.6application
control file parallel write2,102631.7system
51数据库（迁移后）：【由于仅有的3块硬盘被做成了raid5，所以redolog只能被放在raid5阵列上】:
top 5 timed events
eventwaitstime(s)avg wait(ms)% total call timewait class
wait time一部分原因是redo同datafile一起被放到了raid5上，io争用导致的，但也可以看出这个io整体的效率，还是要比之前差很多
所以针对io，做了一系列的测试，包括os上的dd测试（dd if=/dev/zero of=/data/apps/oracle/product/10.2.0/oradata/detail/detail//1gb.file bs=1024 count=1000000），往两个服务器上分别dd一个临时文件，然后用iostat观察io情况，结果如下：
179服务器（迁移前）：
51服务器（迁移后）：
看到这两个io对比，发现51服务器的dm-0逻辑盘的io很高，由于我对lvm和raid，不是太了解，所以问了公司内相关运维，为什么dm-0 io为什么这么高，，给出的回答是正常【此处我表示很无奈】，如果正常的话，那就是raid5写效率对比单块硬盘的写效率低很多。这块技术我很弱，所以暂且相信了运维的回答。
由于这个问题，io写效率低下，只要手工做一个大量的io写，业务就被阻塞，所以公司觉得修改raid5为raid1+0.
最终感觉我想要刨根问底的答案，没有得到，哪位大神如果有见解，可以给点意见。
相关介绍：
=====================================================
=====================iostat详解========================
=====================================================
rrqm/s:  每秒进行 merge 的读操作数目.即 delta(rmerge)/s
 wrqm/s:  每秒进行 merge 的写操作数目.即 delta(wmerge)/s
 r/s:          每秒完成的读 i/o 设备次数.即 delta(rio)/s
 w/s:        每秒完成的写 i/o 设备次数.即 delta(wio)/s
 rsec/s:    每秒读扇区数.即 delta(rsect)/s
 wsec/s:  每秒写扇区数.即 delta(wsect)/s
 rkb/s:      每秒读k字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
 wkb/s:    每秒写k字节数.是 wsect/s 的一半.(需要计算)
 avgrq-sz: 平均每次设备i/o操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
 avgqu-sz: 平均i/o队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
 await:    平均每次设备i/o操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
 svctm:  平均每次设备i/o操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
 %util:      一秒中有百分之多少的时间用于 i/o 操作,或者说一秒中有多少时间 i/o 队列是非空的.即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%,说明产生的i/o请求太多,i/o系统已经满负荷,该磁盘可能存在瓶颈.
 idle小于70% io压力就较大了,一般读取速度有较多的wait.
 同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(io等待所占用的cpu时间的百分比,高过30%时io压力高)
 另外 await 的参数也要多和 svctm 来参考.差的过高就一定有 io 的问题.
 avgqu-sz 也是个做 io 调优时需要注意的地方,这个就是直接每次操作的数据的大小,如果次数多,但数据拿的小的话,其实 io 也会很小.如果数据拿的大,才io 的数据会高.也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲,读定速度是这个来决定的.
另外还可以参考
 svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),svctm 的大小一般和磁盘性能有关,cpu/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加.await 的大小一般取决于服务时间(svctm) 以及 i/o 队列的长度和 i/o 请求的发出模式.如果 svctm 比较接近 await,说明 i/o 几乎没有等待时间；如果 await 远大于 svctm,说明 i/o 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 cpu.
 队列长度(avgqu-sz)也可作为衡量系统 i/o 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 i/o 洪水。