网桥接口导致高CPU利用率

Question

我们实验室的服务器正面临着一个奇怪的问题。具体来说，服务器显示来自低优先级进程的高CPU利用率(蓝色在htop中)，其中50%的核心看起来具有100%的利用率，如下面的屏幕截图所示。

htop高利用率

但是，在正在运行的进程列表中，没有使用此CPU的进程：

$ ps aux --sort pcpu | head -n 20
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0      0     0 ?        S    10:42   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    10:42   0:00 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   10:42   0:00 [kworker/0:0H]
root         6  0.0  0.0      0     0 ?        S    10:42   0:00 [kworker/u96:0]
root         8  0.0  0.0      0     0 ?        S    10:42   0:00 [rcu_sched]
root         9  0.0  0.0      0     0 ?        S    10:42   0:00 [rcu_bh]
root        10  0.0  0.0      0     0 ?        S    10:42   0:00 [migration/0]
root        11  0.0  0.0      0     0 ?        S    10:42   0:00 [watchdog/0]
root        12  0.0  0.0      0     0 ?        S    10:42   0:00 [watchdog/1]
root        13  0.0  0.0      0     0 ?        S    10:42   0:00 [migration/1]
root        14  0.0  0.0      0     0 ?        S    10:42   0:00 [ksoftirqd/1]
root        16  0.0  0.0      0     0 ?        S<   10:42   0:00 [kworker/1:0H]
root        17  0.0  0.0      0     0 ?        S    10:42   0:00 [watchdog/2]
root        18  0.0  0.0      0     0 ?        S    10:42   0:00 [migration/2]
root        19  0.0  0.0      0     0 ?        S    10:42   0:00 [ksoftirqd/2]
root        21  0.0  0.0      0     0 ?        S<   10:42   0:00 [kworker/2:0H]
root        22  0.0  0.0      0     0 ?        S    10:42   0:00 [watchdog/3]
root        23  0.0  0.0      0     0 ?        S    10:42   0:00 [migration/3]
root        24  0.0  0.0      0     0 ?        S    10:42   0:00 [ksoftirqd/3]

问题：爬行后，我们发现当禁用我们在服务器上设置的桥接口(ifdown br0)时，CPU利用率在5-10秒后下降到正常状态。如果我们重新启用桥，那么利用率再次飙升，类似于上面的图片.

What我们已经尝试过：我们尝试禁用libvirtd服务，以防这是服务器上VM的问题，但没有希望。我们还禁用了docker和containerd，但也没有什么改变。我们还删除并重新安装了服务器上的bridge-utils，并将接口重命名为br1，但问题仍然存在。最后，我们还启动了一个不同的内核版本，但仍然什么也没有。

以前有没有人遇到过类似的问题？

Server规范：

$ uname -a
Linux cheetara 4.4.0-174-generic #204-Ubuntu SMP Wed Jan 29 06:41:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="16.04.7 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.7 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

-编辑我们的服务器有两个网络接口p4p1和p4p2。我们已经通过DHCP服务器为每个接口分配了一个静态IP (为了方便起见，假设它们是137.100.1.11和137.100.1.12)。我们的/etc/network/interfaces文件如下所示：

auto lo
iface lo inet loopback

auto p4p1
iface p4p1 inet manual

auto br0
iface br0 inet static
  address 137.100.1.11
  broadcast 137.100.1.255
  netmask 255.255.255.0
  gateway 137.100.1.200
  dns-nameservers 137.100.1.210 137.100.1.220 8.8.8.8 8.8.4.4
  bridge_ports p4p1

auto ib0
iface ib0 inet static
  address 10.1.0.2
  netmask 255.255.255.0

auto ib1
iface ib1 inet static
  address 10.0.0.2
  netmask 255.255.255.0

其中ib0和ib1是与外部网络无关的infiniband接口。

此外，路由如下：

$ ip route show
default via 137.100.1.200 dev br0 onlink
10.0.0.0/24 dev ib1  proto kernel  scope link  src 10.0.0.2 linkdown 
10.1.0.0/24 dev ib0  proto kernel  scope link  src 10.1.0.2 linkdown 
147.102.37.0/24 dev br0  proto kernel  scope link  src 147.102.37.24 

Answer 1

为了更高的速度(在我的例子中是10 Gbps)，NIC卸载功能不能正常工作。因此，CPU正在处理所有的繁重工作。数据包由内核的网络堆栈处理。

启用Jumbo帧(最大MTU大小)和增加环形缓冲区大小降低了CPU的负载。

ip link set dev  mtu 
ethtool -G  rx  tx 

如果NIC卸载功能可用，则应该启用它。

ethtool --offload  tx on rx on

您还可以使用这里列出的其他性能调优方法。来源：https://sysadmin.miniconf.org/2016/lca2016-jamie_班布里奇网络_性能_tuning.html