性能压测时 kprobe 内核探针导致 SYS 内核态 CPU 使用率过高

问题描述

在准生产新机器环境上，利用标准基线工具 BenchmarkSQL 和 Sysbench 对 OceanBase V4.2.1 BP8 数据库进行压测时，发现 %sys 内核态 CPU 利用率大部分时间高达 30% 以上，同时压测工具的压测指标 tpmC 比同等配置下的期望值低 30% 以上。

使用 Kunpeng 920 服务器和 Hygon 7490 服务器集群上均遇到同样的问题，这两套环境安装的操作系统版本均为 Kylin V10 SP3 2403/(Halberd) 的一个最新的内核版本：4.19.90-89.16.v2401.ky10.aarch64/4.19.90-89.16.v2401.ky10.x86_64。

查看监控数据如下：

通过上面的监控数据可以发现：

OBServer 服务器上的 %sys 内核态 CPU 使用率高达 25%，甚至超过了 %user 用户态 CPU 使用率，这在一个数据库服务器压测环境上是不正常的现象。

问题原因

在数据库压测时通过 perf top 命令在 OBServer 服务器上抓取热点函数，发现排在前三的均为内核态函数：

• Kunpeng 920 服务器

  

• Hygon 7490 服务器

  

此处以 Kunpeng 920 服务器为例， kretprobe_hash_unlock 和 security_file_permission 均为之前从未见过的内核热点函数。从函数名排查入手，初步怀疑 Kunpeng 环境上是和 kprobe 和安全模块相关的几个热点函数调用，而 Hygon 环境上跟 CPU 调度和电源管理模块相关。

使用下面的两个命令检查当前被探测的 kprobe 列表：

[root@observer ~]# mount -t debugfs none /sys/kernel/debug/
[root@observer ~]# cat /sys/kernel/debug/kprobes/list

查询结果如下：

• Kunpeng 920 服务器

  

• Hygon 7490 服务器

  

两套环境上 /sys/kernel/debug/kprobes/list 列表中的内容基本完全一致，而在多个其它正常的环境上查询比较后发现，该文件内容均为空。

最终排查下来发现，该场景下性能问题的直接原因就是进行数据库性能压测时操作系统底层一些频繁使用到的系统内核函数调用都被当作内核钩子注册到 Linux 内核动态探针 kprobe 的 list 中去了（可能是用户进程或者内核模块注册进去的），这样一来每当有对应的内核调用发生时，会先执行用户自定义的钩子处理函数进行一些相关的处理。对这些频繁调用的系统内核函数进行探测和钩子函数处理势必会增加 %sys 内核态 CPU 使用率，延长了整体的函数调用路径，最终导致性能压测指标偏低。

而这些系统函数是被部署在主机上的一款主机安全产品长亭牧云(CloudWakler)的 Agent 代理服务在监控主机网络通信和文件系统安全时添加到 /sys/kernel/debug/kprobes/list 列表中去的，只需要停掉对应的 Agent 进程后，list 列表就自动清空。

问题的风险及影响

压测时内核态 CPU 利用率过高，导致基准压测工具的 tpmC 偏低。

适用版本

OceanBase 数据库 V2.x、V3.x、V4.x 版本。

解决方法

在有问题的服务器上尝试执行如下语句：

[root@observer ~]# echo 0 > /sys/kernel/debug/kprobes/enabled

执行完上面的命令后，%sys 内核态 CPU 利用率立刻降低到 10% 以内，且 BenchmarkSQL 压测指标 tpmC 大幅提升。

如果想重启机器后配置仍然自动生效，可以将对应的命令添加到 /etc/rc.d/rc.local 启动自运行脚本中去：

[root@observer ~]# echo "echo 0 > /sys/kernel/debug/kprobes/enabled" >> /etc/rc.d/rc.local

规避方法

如果数据库压测时遇到了跟本文中描述的同样的问题，可以协同网络和系统安全管理人员，在安全允许的情况下，停下并禁用相关的安全监控代理服务：

# systemctl stop cloudwalker-agent
# systemctl disable cloudwalker-agent

或者 disable 掉 cloudwalker-agent 中的 ebpf 检测功能，也可以达到同样的效果。