linux的cpu软中断问题引发的gc cr block lost高等待
早上收到应用反馈应用入库积压严重
初步检查:
1.查看主机性能,vmstat看到d队列较高,其余性能良好
2.查看数据库性能,发现大量gc cr request等待,一般此等待跟本节点内存命中率有关,本地内存块中无结果集,就需要到对端节点命中并请求,网络开销较大,这种问题只有重刷cache解决
3.提取两个节点的awr查看,发现等待时间排第一的是gc cr block lost,
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170919131821728-1175069478.png)
而Estd Interconnect traffic (KB)的耗时是15MB,并没有因为大量的gc请求而引发心跳流量的增长,这就比较奇怪了,照理说gc请求较高,心跳流量会剧增。
那就来针对gc cr block lost这个等待时间来研究了,该等待事件一般跟心跳网卡丢包有关,
进一步查看心跳网卡情况
本案例的rac是使用的双心跳,通过ifconfig查看心跳流量包是否存在丢失
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170919131854540-423658310.png)
可以看到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查看具体情况
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170919131943212-727202499.png)
core 2 的%soft已经100%了,这就比较明显了,确认无疑,就是软中断故障
通过执行脚本修复
cd /opt/ty
./zdatatuner --pinints=eth
执行完,积压立马恢复,数据库等待事件也恢复正常。
【后记】
这个bug在之前已经通过这个脚本修复过,为什么还会出现,回忆在执行之后截止目前,针对这两台主机做过的操作只有加盘,然后对udev重启过,有可能跟该操作有关,所以以后在做类似的操作后,及时执行该脚本,避免再次出现同样的问题。