☰

ブリッジインターフェースにより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サーバー上の VM の問題である可能性を考慮して、サービスを無効にしてみましたが、望みはありませんでした。 と も無効にしました が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

---- 編集 サーバーには 2 つのネットワーク インターフェイス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

関連情報