☰

La interfaz puente provoca una alta utilización de la CPU

tag-icon • tag-icon bridge central-processing-unit htop utilization
La interfaz puente provoca una alta utilización de la CPU

Nos enfrentamos a un problema extraño con un servidor que tenemos en nuestro laboratorio. Específicamente, el servidor muestra una alta utilización de la CPU de procesos de baja prioridad (color azul en htop) y el 50 % de los núcleos parecen tener una utilización del 100 % como se muestra en la captura de pantalla a continuación.

alta utilización

Sin embargo, en la lista de procesos en ejecución no hay ningún proceso que consuma esta 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]

Causa del problema: Después de rastrear un poco, descubrimos que al deshabilitar la interfaz puente que hemos configurado en el servidor ( ifdown br0), la utilización de la CPU cae a estados normales después de 5 a 10 segundos. Si volvemos a habilitar el puente, la utilización vuelve a aumentar, similar a la imagen de arriba.

Lo que hemos probado: Hemos intentado deshabilitar libvirtdel servicio en caso de que se trate de un problema con las máquinas virtuales en el servidor, pero no hay esperanzas al respecto. También hemos desactivado dockery containerd, pero tampoco cambió nada. También eliminamos y reinstalamos bridge-utilsen el servidor y también cambiamos el nombre de la interfaz a br1, pero el problema persiste. Por último, también arrancamos con una versión de kernel diferente, pero todavía nada.

¿Alguien ha enfrentado algún problema similar antes?

Especificaciones del servidor:

$ 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

---- Editar Nuestro servidor tiene dos interfaces de red p4p1y p4p2. Hemos asignado una IP estática a cada interfaz a través del servidor DHCP (por comodidad digamos que son 137.100.1.11y 137.100.1.12). Nuestro /etc/network/interfacesarchivo tiene el siguiente aspecto:

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

donde ib0y ib1son interfaces infiniband no relacionadas con redes externas.

Además la ruta es la siguiente:

$ 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

Respuesta1

Para velocidades más altas (en mi caso, 10 Gbps), la función de descarga de NIC no funciona correctamente. Por lo tanto, la CPU se encarga de todo el trabajo pesado. Los paquetes son manejados por la pila de red del kernel.

Habilitar tramas Jumbo (tamaño MTU MÁX) y aumentar el tamaño del búfer en anillo ha reducido la carga en la CPU.

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

Si la función de descarga de NIC está disponible, debe estar habilitada.

ethtool --offload <interface> tx on rx on

También puede utilizar otros métodos de ajuste del rendimiento que se enumeran aquí. Fuente:https://sysadmin.miniconf.org/2016/lca2016-jamie_bainbridge-network_performance_tuning.html

información relacionada