关于Oracle10.2.0.5+linux5+raid5 IO问题分析

系统环境：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 ClassCPU time 348 95.6 log file sync12,7061213.3Commitlog file parallel write13,5311213.2System I/Oenq: TM - contention492,3622.6Applicationcontrol file parallel write2,102631.7System I/O

51数据库（迁移后）：【由于仅有的3块硬盘被做成了raid5，所以redolog只能被放在raid5阵列上】:

Top 5 Timed Events

EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Classlog file parallel write12,6262201787.2System I/Olog file sync12,9402171786.2Commitcontrol file parallel write1,734854933.7System I/OCPU time
37
14.8
log file switch completion1631721.1Configuration

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各项数值很高，远大于数据盘sda2和sda的io数值，先来研究一下dm-0的各项数据 。

       首先w/s显示，写请求次数对比数据盘的sda和sda2来说，写请求2242.33太高，而相对应的avgrq-sz可以看到，每次平均写才8，基本都是小文件，但请求很频繁，%iowait 24.81%，再结合avgqu-sz、svctm和%util来看，导致io队列太长，io负载已经很高，确定存在瓶颈。

       同时对比sda，sda2数据盘的io数据，差异比较大的首先就是wsec/s（每秒写扇区数），迁移前后，wsec/s差了8.9倍，在同样业务，同样数据量的情况下，差这么多，完全不正常，个人觉得，估计就是迁移后，频繁的小io写请求，加之硬盘转速不够，导致io瓶颈被放大。而在同样数据量、业务逻辑的两个io环境，迁移后io为何出现如此频繁的小io写请求，猜测应该和raid5数据交叉校验有关。RAID5把数据和相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上，每次写数据都会用其他盘区的校验数据去校验正在 io的数据是否有效和一致，应该就是造成频繁小IO写的原因之一。

以上只是个人的一个认识和理解，由于刚刚恶补IO这块的知识，所以错误在所难免，欢迎纠错！

相关介绍：

=====================================================

=====================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 洪水.

=====================================================

========================raid 5========================

=====================================================

       RAID 5 是一种存储性能、数据安全和存储成本兼顾的存储解决方案。 RAID 5可以理解为是RAID 0和RAID 1的折中方案。RAID 5可以为系统提供数据安全保障，但保障程度要比Mirror低而磁盘空间利用率要比Mirror高。RAID 5具有和RAID 0相近似的数据读取速度，只是多了一个奇偶校验信息，写入数据的速度比对单个磁盘进行写入操作稍慢。同时由于多个数据对应一个奇偶校验信息，RAID 5的磁盘空间利用率要比RAID 1高，存储成本相对较低。

 运作

       以四个硬盘组成的RAID 5为例，其数据存储方式如概述中的图片所示：图中，P0为D0、D1和D2的奇偶校验信息，其它以此类推。由图中可以看出，RAID 5不对存储的数据进行备份，而是把数据和与其相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据损坏后，利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。

校验

       RAID5校验位算法原理

       P=D1 xor D2 xor D3 … xor Dn （D1,D2,D3 … Dn为数据块，P为校验，xor为异或运算）

       XOR(Exclusive OR)的校验原理如下表：

A值

B值

Xor结果

0

0

0

1

0

1

0

1

1

1

1

0

        这里的A与B值就代表了两个位，从中可以发现，A与B一样时，XOR结果为0，A与B不一样时，XOR结果就是1，而且知道XOR结果和A与B中的任何一个数值，就可以反推出另一个数值。比如A为1，XOR结果为1，那么B肯定为0，如果XOR结果为0，那么B肯定为1。这就是XOR编码与校验的基本原理。

读写

        用简单的语言来表示，至少使用3块硬盘（也可以更多）组建RAID5磁盘阵列，当有数据写入硬盘的时候，按照1块硬盘的方式就是直接写入这块硬盘的磁道，如果是RAID5的话这次数据写入会根据算法分成3部分，然后写入这3块硬盘，写入的同时还会在这3块硬盘上写入校验信息，当读取写入的数据的时候会分别从3块硬盘上读取数据内容，再通过检验信息进行校验。当其中有1块硬盘出现损坏的时候,就从另外2块硬盘上存储的数据可以计算出第3块硬盘的数据内容。也就是说raid5这种存储方式只允许有一块硬盘出现故障，出现故障时需要尽快更换。当更换故障硬盘后，在故障期间写入的数据会进行重新校验。 如果在未解决故障又坏1块，那就是灾难性的了。

存储

        RAID5把数据和相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上，其中任意N-1块磁盘上都存储完整的数据，也就是说有相当于一块磁盘容量的空间用于存储奇偶校验信息。因此当RAID5的一个磁盘发生损坏后，不会影响数据的完整性，从而保证了数据安全。当损坏的磁盘被替换后，RAID还会自动利用剩下奇偶校验信息去重建此磁盘上的数据，来保持RAID5的高可靠性。