OceanBase数据库软中断过高问题定位分析一、问题描述 A和B资源池部署了OceanBase数据库集群，其中A资源池内的鲲鹏服务器在用sysbench压测时存在网卡软中断占用过高的问题，但是B资源池内的鲲鹏服务器无该问题。软中断过高的问题会导致服务器部署的OB数据库集群TPS/QPS只有正常集群性能的三分之一。伙伴尝试将网卡软中断打散到全部的CPU、也尝试中断绑核至numa0、调整ringbuffer、网卡队列数等操作，但是软中断依旧有占比高的问题。【具体现象】中断队列数24，中断绑核绑在0-23核心，0-23核软中断si几乎为100%，CPU用户态和系统态占比几乎为0。二、测试场景 SysBench测试用例：点查 / 250张表 / 并发 800 / 每张表记录数10W / 只连接从zone 240机器的obproxy 三、环境配置配置 A资源池异常节点 B资源池正常节点 OS BCLinux 21.10U3 LTS BCLinux 21.10U3 LTS CPU 4 * 5250 4 * 5250 网卡 SP681 2*25GE - 网卡驱动版本 hinic3 17.6.9.2 Mlx5_core 5.0-0 网卡固件版本 15.19.2.10 14.31.1014 软中断情况 24个核心软中断几乎都100% 24个核心软中断只有30% 四、问题分析 4.1 环境对比 4.1.1 负载分析检查CPU、磁盘、网络、内存负载情况，其中24个cpu核心，软中断占比在100%左右。但是业务口bond1 IO的网络IO在30MB/s，不存在网络瓶颈。同步使用iperf3测试网络IO，可达1GB/s以上，且si软中断不高。 4.1.2 硬件配置&OS配置参数检查网卡驱动问题排查：排查发现，异常节点与正常节点的网卡型号确实存在差异。在A资源池中，异常节点同时出现了SP681和Netswift两种不同厂商的网卡。鉴于同一资源池内多厂商网卡同时出现驱动问题的概率极低，我们将配置排查的重点转向运维人员此前对网卡及中断相关参数所做的修改。网卡、中断参数配置：检查了网卡均组的bond4作为业务口，且均为25GE网卡，未出现错误使用电口作为业务口的情况。进一步排查发现，AB资源池节点在中断绑核、中断聚合参数及ringbuffer配置上存在不一致。我们对所有差异点进行了统一修正，但A资源池异常节点的软中断过高问题仍未改善。增加中断绑核的数量：尝试修改网卡队列数（24 -> 48），并绑网卡中断至0-47核，重新进行sysbench性能测试，软中断变成48个核心软中断si 占比100%，sysbench性能提升100%，可以判断sysbench压测的阻塞点主要在软中断的处理上。 4.1.3 BIOS配置检查异常节点相较正常节点，额外修改了PCIeSRIOVSupport为Disabled和PxeRetry次数（1->99）。两BIOS配置与网卡软中断过高问题，均无明显关系，修改BIOS配置和正常节点一致后，软中断问题未解决。两个BIOS配置的作用： ●PCIeSRIOVSupport：决定虚拟机管理程序（Hypervisor）是否可以创建PCIe设备的虚拟实例，主要跟虚拟化场景有关，和该裸机测试场景没有关系。 ●PxeRetry：在通过网络引导（PXE，Preboot eXecution Environment）过程中，当系统尝试从网络引导服务器（如 DHCP 服务器或 TFTP 服务器）获取引导镜像或配置信息时，如果失败会进行的重试次数。 4.2 热点函数分析通过cat /proc/softirqs判断软中断分类，主要以NET_RX 为主，但是相比正常节点的软中断数量少非常多（所有的类型的软中断都少很多）。所以考虑是网络收发包的流程中存在瓶颈点，而软中断的占比较高，猜测是软中断的处理过程因为某些原因阻塞了，执行perf top命令查询热点函数，意图发现瓶颈点。 perf top查询压测过程中，正常和异常节点中的热点函数存在差异。正常数据库节点主要以oceanbase相关函数为主，但是异常节点中，存在queued_spin_lock_slowpath、asp_spin_lock这些锁相关函数。在历史项目中有遇到过，压测方式错误导致的queued_spin_lock_slowpath热点函数过高的问题，主要是因为建立一次连接执行一次sql，然后关闭连接，频繁的建立数据库链接导致的问题。但是异常节点的OB默认连接数配置很高，不会存在连接数不足的情况。后续计划通过火焰图来检查热点函数相关的调用栈信息。异常节点热点函数： Samples: 6M of event 'cycles:ppp', 4000 Hz, Event count (approx.): 80336457684 Overhead Shared Object Symbol 19.87% [kernel] [k] finish_task_switch 7.60% [kernel] [k] queued_spin_lock_slow 3.23% [kernel] [k] arch_cpu_idle 2.57% perf [.] ordered_events_queue 1.94% [kernel] [k] asp_spin_lock 1.93% [kernel] [k] zap_pte_range 1.84% observer [.] oceanebase::comt::ObTHW 1.42% [kernel] [k] __wake_up_common_lock 0.93% [kernel] [k] __slab_free 0.87% obproxy [.] oceanebase::common::Ob 0.76% [kernel] [k] net_ip_white_list_account 0.69% [kernel] [k] page_remove_rmap 0.61% [kernel] [k] ep_poll 0.57% [kernel] [k] e10_svc_common 0.57% [kernel] [k] hinic3_send_one_skb 正常节点热点函数： Samples: 6M of event 'cycles:ppp', 4000 Hz, Event count (approx.): 6.05% [kernel] [k] finish_task_switch 1.92% observer [.] occanbase:isql::ObInfiee 1.79% observer [.] oceanbase:isql::ObExpre 4.3 火焰图分析系统冷热火焰图均存在queued_spin_lock_slowpath，占比大致为10%左右，正常节点火焰图不存在该热点函数。分析调用栈，发现ip_local_out函数以下的调用栈是一致的，ip_local_out函数以上的调用栈存在差异点。并且secmodel_check、net_asp_logic_access_check不是操作系统自带的内核标准函数，像是某种安全检查类的函数，需要排查这些函数的来源。 4.4 查询问题函数来源查询到resguard_linux模块中包含ASPLogicAccessCheck等热点函数，但是正常节点的设备并没有该内核模块。分析操作系统版本安装镜像和系统内核，均不存在差异点，考虑是系统安装后的后续改动引入的问题。lsmod | grep resguard 排查到该模块resguard_linux有两个进程在使用。 4.5 排查引入/使用resguard_linux内核模块的进程通过grep -rn命令全局搜索resguard_linux相关信息，发现异常节点服务器存在resguard_linux相关的内容。进入XXX软件安装目录后，发现该软件的安装脚本涉及resguard_linux和secmodel_linux内核模块部署，至此，确认问题函数及内核模块来源为XXX软件。五、性能测试查询正在执行的XXX进程，并kill掉。然后进入XXX软件安装目录，执行bash uninstall卸载命令。该命令会卸载XXX软件、以及resguard_linux和secmodel_linux内核模块。卸载resguard_linux模块后，重新测试sysbench，800并发TPS大幅提升至60W+，软中断恢复正常状态，且queued_spin_lock_slowpath 和 asp_spin_lock热点函数消失，问题修复。修复后的热点函数： | Overhead | Shared Object | Symbol | | :--- | :--- | :--- | | 5.50% | [kernel] | [k] finish_task_switch | | 3.63% | [kernel] | [k] __wake_up_common_lock | | 2.64% | obproxy | [.] oceanbase::obproxy::net | | 2.53% | [kernel] | [k] arch_cpu_idle | | 2.04% | obproxy | [.] oceanbase::common::ObL | | 1.84% | [kernel] | [k] __slab_free | | 1.61% | obproxy | [.] oceanbase::obproxy::pr | | 1.59% | obproxy | [.] oceanbase::common::ObL | | 1.42% | obproxy | [.] oceanbase::obproxy::net | | 1.40% | [kernel] | [k] __softirqentry_text_st | | 1.34% | obproxy | [.] oceanbase::obproxy::ev | | 1.27% | obproxy | [.] oceanbase::common::ObL | | 1.22% | obproxy | [.] oceanbase::obproxy::net | | 1.20% | [kernel] | [k] skb_release_data | 修复后的火焰图： secmodel_check和net_asp_logic_access_check等函数未出现六、总结 XXX软件会对网络收发包做特殊处理，通过hook函数进行拦截，进行安全检查和流量管控等动作。额外的安全检查动作和流量管控导致了spin_lock锁的争抢，致使软中断处理的效率大幅下降，软中断的占比过高，sysbench性能大幅下降。