linux的cpu软中断问题引发的gc cr block lost高等待

早上收到应用反馈应用入库积压严重

初步检查：

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重启过，有可能跟该操作有关，所以以后在做类似的操作后，及时执行该脚本，避免再次出现同样的问题。

转载于:https://www.cnblogs.com/tonnytangy/p/7551358.html