☰

Bridge-Schnittstelle verursacht hohe CPU-Auslastung

tag-icon • tag-icon bridge central-processing-unit htop utilization
Bridge-Schnittstelle verursacht hohe CPU-Auslastung

Wir haben ein seltsames Problem mit einem Server in unserem Labor. Genauer gesagt zeigt der Server eine hohe CPU-Auslastung durch Prozesse mit niedriger Priorität (blaue Farbe in htop), wobei 50 % der Kerne scheinbar eine Auslastung von 100 % aufweisen, wie im Screenshot unten zu sehen ist.

htop hohe Auslastung

In der Liste der laufenden Prozesse gibt es jedoch keinen Prozess, der diese CPU verbraucht:

$ 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]

Ursache des Problems: Nach einigem Herumprobieren haben wir festgestellt, dass ifdown br0die CPU-Auslastung nach 5-10 Sekunden auf den Normalwert abfällt, wenn wir die Bridge-Schnittstelle deaktivieren, die wir auf dem Server eingerichtet haben ( ). Wenn wir die Bridge wieder aktivieren, steigt die Auslastung wieder an, ähnlich wie im Bild oben.

Was wir versucht haben: Wir haben versucht, libvirtdden Dienst zu deaktivieren, falls dies ein Problem mit den VMs auf dem Server war, aber das hat nichts gebracht. Wir haben auch dockerund deaktiviert containerd, aber auch das hat sich nichts geändert. Wir haben auch entfernt und auf dem Server neu installiert bridge-utilsund die Schnittstelle in br1 umbenannt, aber das Problem besteht immer noch. Zuletzt haben wir auch mit einer anderen Kernelversion gebootet, aber immer noch nichts.

Hatte jemand schon einmal ein ähnliches Problem?

Serverspezifikationen:

$ 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

---- Bearbeiten Unser Server hat zwei Netzwerkschnittstellen p4p1und p4p2. Wir haben jeder Schnittstelle über den DHCP-Server eine statische IP zugewiesen (der Einfachheit halber sagen wir, sie sind 137.100.1.11und 137.100.1.12). Unsere /etc/network/interfacesDatei sieht folgendermaßen aus:

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

wobei ib0und ib1Infiniband-Schnittstellen nicht mit externen Netzwerken verbunden sind.

Außerdem ist die Streckenführung wie folgt:

$ 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

Antwort1

Bei höheren Geschwindigkeiten (in meinem Fall waren es 10 Gbit/s) funktioniert die NIC-Offload-Funktion nicht richtig. Daher übernimmt die CPU die ganze schwere Arbeit. Die Pakete werden vom Netzwerkstapel des Kernels verarbeitet.

Durch die Aktivierung von Jumbo-Frames (MAX. MTU-Größe) und die Erhöhung der Ringpuffergröße wurde die CPU-Belastung reduziert.

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

Wenn die NIC-Offload-Funktion verfügbar ist, sollte sie aktiviert werden.

ethtool --offload <interface> tx on rx on

Sie können auch andere hier aufgeführte Methoden zur Leistungsoptimierung verwenden. Quelle:https://sysadmin.miniconf.org/2016/lca2016-jamie_bainbridge-network_performance_tuning.html

verwandte Informationen