时间：2021-07-01 10:21:17 帮助过：34人阅读
刚发现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 sync 12,706 12 1 3.3 Commit
log file parallel write 13,531 12 1 3.2 System I/O
enq: TM - contention 4 9 2,362 2.6 Application
control file parallel write 2,102 6 3 1.7 System
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 洪水。
