☰

Интерфейс моста вызывает высокую загрузку ЦП

tag-icon • tag-icon bridge central-processing-unit htop utilization
Интерфейс моста вызывает высокую загрузку ЦП

Мы столкнулись со странной проблемой с сервером, который есть в нашей лаборатории. В частности, сервер показывает высокую загрузку ЦП от низкоприоритетных процессов (синий цвет в htop), при этом 50% ядер, по-видимому, имеют 100% загрузку, как показано на снимке экрана ниже.

htop высокая загрузка

Однако в списке запущенных процессов нет процесса, потребляющего этот процессор:

$ 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), загрузка ЦП падает до нормального состояния через 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. Каждому интерфейсу мы назначили статический IP через DHCP-сервер (для удобства будем называть их 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 Гбит/с) функция разгрузки сетевого адаптера не работает должным образом. Следовательно, всю тяжелую работу выполняет ЦП. Пакеты обрабатываются сетевым стеком ядра.

Включение Jumbo-кадров (максимальный размер MTU) и увеличение размера кольцевого буфера снизило нагрузку на ЦП.

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

Если доступна функция разгрузки сетевой карты, ее следует включить.

ethtool --offload <interface> tx on rx on

Вы также можете использовать другие методы настройки производительности, перечисленные здесь. Источник:https://sysadmin.miniconf.org/2016/lca2016-jamie_bainbridge-network_performance_tuning.html

Связанный контент