☰

橋接介面導致CPU利用率高

tag-icon • tag-icon bridge central-processing-unit htop utilization
橋接介面導致CPU利用率高

我們實驗室的伺服器面臨一個奇怪的問題。具體來說，伺服器顯示低優先權進程（圖中的藍色htop）的高 CPU 使用率，其中 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 秒後下降到正常狀態。如果我們重新啟用橋接器，那麼利用率會再次飆升，類似於上圖。

我們已經嘗試過： 我們已嘗試停用libvirtd服務，以防伺服器上的虛擬機器出現問題，但沒有希望。我們也禁用了docker和containerd，但也沒有任何改變。我們也會在伺服器上刪除並重新安裝，bridge-utils並將介面重命名為 br1，但問題仍然存在。最後，我們也使用不同的核心版本啟動，但仍然沒有任何結果。

以前有人遇到類似的問題嗎？

伺服器規格：

$ 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

答案1

對於更高的速度（在我的例子中是 10 Gbps），NIC 卸載功能無法正常工作。因此，CPU 正在處理所有繁重的工作。資料包由核心的網路堆疊處理。

啟用巨型幀（最大 MTU 大小）並增加環形緩衝區大小可以減少 CPU 的負載。

ip link set dev <interface> mtu <value>
ethtool -G <interface> rx <value> tx <value>

如果 NIC 卸載功能可用，則應啟用它。

ethtool --offload <interface> tx on rx on

您也可以使用此處列出的其他效能調整方法。來源：https://sysadmin.miniconf.org/2016/lca2016-jamie_bainbridge-network_performance_tuning.html

相關內容