☰

브리지 인터페이스로 인해 CPU 사용률이 높아짐

tag-icon • tag-icon bridge central-processing-unit htop utilization
브리지 인터페이스로 인해 CPU 사용률이 높아짐

우리 연구실에 있는 서버에 이상한 문제가 발생했습니다. 특히 서버는 htop아래 스크린샷에 표시된 것처럼 코어의 50%가 100% 활용도로 나타나는 낮은 우선순위 프로세스(그림의 파란색)에서 높은 CPU 활용도를 보여줍니다.

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 br0CPU 사용률이 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

---- 편집 우리 서버에는 두 개의 네트워크 인터페이스가 있습니다 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는 외부 네트워킹과 관련되지 않은 인피니밴드 인터페이스입니다.

또한 라우팅은 다음과 같습니다.

$ 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

더 빠른 속도(제 경우에는 10Gbps)의 경우 NIC 오프로드 기능이 제대로 작동하지 않습니다. 따라서 CPU는 모든 무거운 작업을 처리합니다. 패킷은 커널의 네트워크 스택에 의해 처리됩니다.

점보 프레임(MAX 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

관련 정보