记一次oracle rac节点IO慢的故障排查

客户现场两个rac节点，使用2+3的一体机架构。

客户反馈说节点1特别慢，节点2性能正常。客户有个监控软件，分别截取了两个节点的性能数据

节点1异常的节点：

节点2正常的节点：

可以看到节点2异常节点的IO响应特别慢。

查询节点1同时负载也特别高

节点1：

节点2：

后来分析是因为节点1的IO特别差，导致节点1上请求积压，所以导致节点1的负载特别高。

查看节点的io，发现节点1的IO特别小，看上去感觉IO很闲

在这么大负载的情况下，IO这么闲就肯定有问题。

然后去查存储节点2：

/opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp -Cache -LALL -aALL

cache全writethrough了。

而存储节点1和存储节点3的cache策略是正常的，正常应该是writeback。

writeback的意思就是在落盘操作的时候，只写cache，不写物理磁盘。

writethrough是即写cache，又写物理磁盘，这个在生产环境中是坚决有问题的。

从提示信息可以看出来，当磁盘在BBU电池坏了的时候，就不写cache直接落物理盘了，此时基本可以判断是bbu坏了

/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -aAll

查询bbu状态

此时为了恢复业务，先强制把磁盘设置为在bbu坏了的时候，也writeback的策略，此时cache的供电就靠主机接入的电源了，当主机断电的时候，该节点cache上的数据会丢失。

但是由于有三个存储节点，做的三副本，所以只有一个节点数据丢失并不会影响数据。

/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l12 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l11 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l10 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l9 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l8 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l7 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l6 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l5 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l4 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l3 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l2 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l1 -a0
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -l0 -a0

 

-a后面接的是adapter的编号，-l后面接的是哪个磁盘；分别对应下面截图的内容：

修改后，观察计算节点的io就发现起来了

咨询客户侧的监控，发现io的响应时间也下去了