1.问题环境

2.问题描述

数据库业务运行过程中，发现读写速度缓慢，软中断占用cpu过高。

目前环境已经恢复需要排查原因，数据库读写慢的时候发现软中断占用cpu很高，图一是出现问题的时候现场直接在环境上看的，从sosreport上面看并不高，但是收集日志的时候问题现象还在。

docker这些包用的不是系统自带源的，开了numa，irqbalance服务是正常运行的，其中perf.data.old太大了 打不开，perf.data可以，系统日志中没发现异常，内存也正常，其中cpu可以看到部分核心使用率很高的情况。

3.问题分析

3.1.分析系统环境

3.1.1. 查看网络配置

查看网络情况，enp133s0f0和enp134s0f0配置mode4组成bond0。

查看./sos_commands/networking/ethtool_-S_enp133s0f0和./sos_commands/networking/ethtool_-S_enp134s0f0，发现两个网卡都存在大量的rxX_cache_full的情况。

查看bond0的rxDrop情况。

查看enp133s0f0和enp134s0f0网卡队列情况和ring buffer个数，两个网卡的网卡队列数为63，ring buffer个数为1024。

查看./proc/net/softnet_stat发现第二列和第三列都存在很大的值，查看对应的内核参数net.core.netdev_max_backlog为10000和net.core.netdev_budget为300。

• 第一列：processed：表示处理了多少个数据包。

• 第二列：dropped：表示丢弃了多少个数据包，因为队列满了或者内存不足。

• 第三列：time_squeeze：表示发生了多少次时间压缩，即软中断处理时间超过了预设的限制。

/proc/net/softnet_stat 的第三列值持续增加，这通常意味着软中断处理时间不足以处理所有入站数据包。在这种情况下，可以尝试增加 net.core.netdev_budget 的值，以允许在单次软中断中处理更多的数据包，从而减少因为处理不及时而推迟或丢弃的数据包数量。

3.1.2. 查看系统服务

发现irqbalance服务开启状态。

3.1.3 .查看CPU情况

可见CPU是96核，分4个NUMA节点，每个numa节点24个CPU核。

查看./sys/class/net/enp133s0f0/device/numa_node和./sys/class/net/enp134s0f0/device/numa_node，可见两个网络接口都在numa node 2上。

3.2 .分析sa日志

3.2.1. 分析内存使用情况

sar -rh -f sa21，查看当时的内存使用情况，可见空闲内存较少，缓存较大。查看./proc/sys/vm/min_free_kbytes为524288，较小。

sar -rh -f sa20，查看前一天的内存使用情况，内存使用和问题发生时相同。

3.2.2. 分析CPU使用情况

sar -u -f sa21，查看cpu使用情况，%system部分占用CPU较高。

sar -u -f sa20，查看前一天的CPU使用情况，前一天cpu使用情况和问题发生时类似。

3.2.3. 分析负载情况

sar -q -f sa21，查看当时的系统负载，负载偏高。

 sar -q -f sa20，查看前一天的系统负载情况，可见前一天的系统负载也偏高，和问题发生时没有明显差异。

3.3. 分析messages日志

查看messages日志，日志中没有明确的报错信息。

3.4 分析perf采集

4.问题小结

1、根据CPU核数及NUMA情况，结合网卡的所属numa节点，建议调小网卡队列数，调大网卡的ring buffer。

2、根据查看的./proc/net/softnet_stat情况，第三列的增加表明了软中断处理时间的不足，而 net.core.netdev_budget 参数的调整可以帮助提高在一个软中断周期内可以处理的数据包数量，从而改善性能。建议将net.core.netdev_budget调为1024。

3、发现irqbalance服务开启状态，建议关闭irqbalance服务。

5.相关建议