早上收到应用反馈应用入库积压严重
初步检查：
1.查看主机性能，vmstat看到d队列较高，其余性能良好
2.查看数据库性能，发现大量gc cr request等待，一般此等待跟本节点内存命中率有关，本地内存块中无结果集，就需要到对端节点命中并请求，网络开销较大，这种问题只有重刷cache解决
3.提取两个节点的awr查看，发现等待时间排第一的是gc cr block lost，
而Estd Interconnect traffic (KB)的耗时是15MB，并没有因为大量的gc请求而引发心跳流量的增长，这就比较奇怪了，照理说gc请求较高，心跳流量会剧增。
那就来针对gc cr block lost这个等待时间来研究了，该等待事件一般跟心跳网卡丢包有关，
进一步查看心跳网卡情况
本案例的rac是使用的双心跳，通过ifconfig查看心跳流量包是否存在丢失
可以看到eth3心跳网卡的overruns较高
RX overruns: 表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显，overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一。
这个现象就让人联想到之前出现的CPU软中断的问题，可以通过
mpstat -P ALL 2 3查看具体情况
core 2 的%soft已经100%了，这就比较明显了，确认无疑，就是软中断故障
通过执行脚本修复
cd /opt/ty
./zdatatuner --pinints=eth
执行完，积压立马恢复，数据库等待事件也恢复正常。
【后记】
这个bug在之前已经通过这个脚本修复过，为什么还会出现，回忆在执行之后截止目前，针对这两台主机做过的操作只有加盘，然后对udev重启过，有可能跟该操作有关，所以以后在做类似的操作后，及时执行该脚本，避免再次出现同样的问题。