Home >Database >Mysql Tutorial >关于Oracle10.2.0.5+Linux5+RAID5 IO问题分析
刚发现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 洪水。