H330RAID卡对RAID5支持不友好导致磁盘IO异常缓慢
BI有一个数据库,主要存放的是hadoop处理过的结果信息,1.6TB,只有一个业务部门用,11.2.0.4版本,非归档,没备份。
对BI系统来讲,通常数据都可以从其他数据库或者其他途径弄到,所以数据库的重要性不是那么高,我们一共有两套BI数据库,之前都是非归档,没备份,我们提过几次为这俩数据库搭建DG,领导一直没同意,业务部门也说数据不重要,出问题可以重新抽数据。
前段时间,悲催了,其中的一个BI数据库服务器(DELL R930,24块磁盘做的RAID5)由于监控卡故障,磁盘损坏没有报警,导致同时坏了4块磁盘的时候,磁盘分区直接看不到了,数据库直接挂掉的时候才发现硬件故障。
这时要重抽数据,确出了问题,基础数据可以重新从其他数据库抽取到,业务人员估算大概需要2-3天可以抽取完成。但是一些配置信息等核心数据,都是在BI数据库配置好的,和其他数据库没有直接的关系,这些数据库并不能从其他数据库抽取到。
这下领导慌了,还好,坏的4块盘并不是同一个RAID,在DELL工程师的帮助下,操作系统终于起来,但盘没敢直接换,我们赶紧异地备份数据(在本地备份怕大量的I/O操作会触发问题),在另一台服务器上恢复成功后,才换的盘,换完之后,直接重新做了RAID重新安装了操作系统。
这下领导意识到,BI系统并不是不需要备份的,直接批了两台服务器给我们搭建备库使用(其中一台DELL R730公司直接有闲置服务器,另一台DELL R930正在采购,现在还没到货)。在给另一台数据库搭建备库的过程中,发现这台BI数据库的服务器特别的慢,1.6TB的数据使用RMAN备份用了22小时还多,这是不正常的,在向备库服务器传输备份的时候,发现每秒只能传30MB,千兆网,别的服务器传文件都可以打岛100MB/s以上,而且我操作的时间是在周末,数据库根本就没人使用。
[oracle@SL010A-BIDB02 u01]$ scp ODS_DATA01.DBF 10.0.2.100:/u01/ oracle@10.0.2.100's password: ODS_DATA01.DBF 8% 2658MB 31.2MB/s 16:05 ETA
注:本文的ODS_DATA01.DBF为本案例测试文件,大小为32GB。
使用dd命令测试了一下,发现主库的磁盘I/O特别的低,是备库(新给的DELL R730服务器),而且这两台服务器都是同一型号DELL R730,配置也一模一样。
主库:
[oracle@SL010A-BIDB02 u01]$ dd if=ODS_DATA01.DBF of=xxx bs=2048k 16383+1 records in 16383+1 records out 34358697984 bytes (34 GB) copied, 353.757 s, 97.1 MB/s
备库:
[oracle@SL010A-BIDB03 u01]$ dd if=ODS_DATA01.DBF of=xxx bs=2048k 16383+1 records in 16383+1 records out 34358697984 bytes (34 GB) copied, 88.0502 s, 390 MB/s
这里测试的是连读带写的速度,也测试了纯读、纯写的速度,纯读和纯写的速度,主库比备库慢了10备不止,将这个问题反映给了硬件维护人员,起初我以为是RAID5有磁盘损坏了,RAID5如果有坏盘的情况,I/O能力就会大幅下降。
而硬件维护人员检查后,并没有发现硬件故障,他们测试也发现那台机器的I/O异常。联系了DELL的售后,DELL的售后在收集一些信息后,确定是H330型号的RAID卡没有缓存 ,对RAID5支持不友好导致的,这款RAID卡,做RAID5,就会越用越慢。
通过cat /proc/scsi/scsi命令可以查看RAID卡的型号,我们这台主库服务器确实是H330的RAID卡,备库用的是H730型号的RAID卡就没有问题,最终的解决方案是,将RAID5换成RAID10或者更换RAID卡。
由于业务人员对现在的I/O情况还可以接受,我们最终采用的是第三种方案,挺着。
经过排查发现,还有一些DELL R730服务器使用的是H310型号的RAID卡,而且H310型号的RAID卡做RAID5也存在这样的问题。这种情况已经上报,目前得到的结果就是还能接受,先挺着。
手里有DELL R720或者R730服务器的,可以关注一下,DELL的售后说只对RAID5有影响。还有采购硬件的时候,最好选择原厂发货,代理商有时候为了降低成本,很坑爹的。