네트워크 문제 해결 및 성능 튜닝


Red Hat Enterprise Linux 10

네트워킹 문제 디버깅 및 해결

Red Hat Customer Content Services

초록

네트워크 설정 튜닝은 고려해야 할 여러 요인이 있는 복잡한 프로세스입니다. 예를 들어 CPU-to-메모리 아키텍처, CPU 코어 양 등이 포함됩니다. Red Hat Enterprise Linux는 대부분의 시나리오에 최적화된 기본 설정을 사용합니다. 그러나 특정 경우에는 처리량 또는 대기 시간을 늘리거나 패킷 드롭과 같은 문제를 해결하기 위해 네트워크 설정을 조정해야 할 수 있습니다.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

Jira를 통해 피드백 제출 (계정 필요)

  1. Jira 웹 사이트에 로그인합니다.
  2. 상단 탐색 바에서 생성을 클릭합니다.
  3. 요약 필드에 설명 제목을 입력합니다.
  4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 대화 상자 하단에서 생성 을 클릭합니다.

1장. 네트워크 어댑터 설정 튜닝

40Gbps 이상의 고속 네트워크에서 네트워크 어댑터 관련 커널 설정의 특정 기본값이 패킷 드롭 및 성능 저하의 원인이 될 수 있습니다. 이러한 설정을 조정하면 이러한 문제를 방지할 수 있습니다.

패킷 삭제 속도가 발생하면 이더넷 장치의 링 버퍼 크기를 늘리면 애플리케이션이 데이터 손실, 시간 초과 또는 기타 문제가 보고됩니다.

수신 링 버퍼는 장치 드라이버와 NIC(네트워크 인터페이스 컨트롤러) 간에 공유됩니다. 카드는 전송(TX)을 할당하고(RX) 링 버퍼를 수신합니다. 이름에서 알 수 있듯이 링 버퍼는 오버플로가 기존 데이터를 덮어쓰는 순환 버퍼입니다. NIC에서 커널로 데이터를 이동하는 두 가지 방법, 하드웨어 인터럽트 및 소프트웨어 인터럽트( softIRQs라고도 함)가 있습니다.

커널은 장치 드라이버가 이를 처리할 수 있을 때까지 RX 링 버퍼를 사용하여 들어오는 패킷을 저장합니다. 장치 드라이버는 일반적으로 SoftIRQs를 사용하여 RX 링을 드레이닝하여 들어오는 패킷을 sk_buff 또는 skb 라는 커널 데이터 구조에 배치하여 커널과 관련 소켓을 소유하는 애플리케이션까지 이동합니다.

커널은 TX 링 버퍼를 사용하여 네트워크로 전송해야 하는 발신 패킷을 보관합니다. 이러한 링 버퍼는 스택 하단에 있으며 패킷 드롭이 발생할 수 있는 중요한 지점이며 네트워크 성능에 부정적인 영향을 미칩니다.

프로세스

  1. 인터페이스의 패킷 삭제 통계를 표시합니다.

    # ethtool -S enp1s0
        ...
        rx_queue_0_drops: 97326
        rx_queue_1_drops: 63783
        ...
    Copy to Clipboard Toggle word wrap

    명령 출력은 네트워크 카드 및 드라이버에 따라 다릅니다.

    카운터 삭제 또는 삭제 카운터의 값이 높으면 사용 가능한 버퍼가 커널에서 패킷을 처리할 수 있는 것보다 더 빠르게 채워지는 것을 나타냅니다. 링 버퍼를 늘리면 이러한 손실을 방지하는 데 도움이 될 수 있습니다.

  2. 최대 링 버퍼 크기를 표시합니다.

    # ethtool -g enp1s0
     Ring parameters for enp1s0:
     Pre-set maximums:
     RX:             4096
     RX Mini:        0
     RX Jumbo:       16320
     TX:             4096
     Current hardware settings:
     RX:             255
     RX Mini:        0
     RX Jumbo:       0
     TX:             255
    Copy to Clipboard Toggle word wrap

    사전 설정 최대값 섹션의 값이 현재 하드웨어 설정 섹션보다 크면 다음 단계의 설정을 변경할 수 있습니다.

  3. 인터페이스를 사용하는 NetworkManager 연결 프로필을 확인합니다.

    # nmcli connection show
    NAME                UUID                                  TYPE      DEVICE
    Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0
    Copy to Clipboard Toggle word wrap
  4. 연결 프로필을 업데이트하고 링 버퍼를 늘립니다.

    • RX 링 버퍼를 늘리려면 다음을 입력합니다.

      # nmcli connection modify Example-Connection ethtool.ring-rx 4096
      Copy to Clipboard Toggle word wrap
    • TX 링 버퍼를 늘리려면 다음을 입력합니다.

      # nmcli connection modify Example-Connection ethtool.ring-tx 4096
      Copy to Clipboard Toggle word wrap
  5. NetworkManager 연결을 다시 로드합니다.

    # nmcli connection up Example-Connection
    Copy to Clipboard Toggle word wrap
    중요

    NIC가 사용하는 드라이버에 따라 링 버퍼에서 변경하면 곧 네트워크 연결이 중단될 수 있습니다.

패킷 삭제 속도가 발생하면 이더넷 장치의 링 버퍼 크기를 늘리면 애플리케이션이 데이터 손실, 시간 초과 또는 기타 문제가 보고됩니다.

링 버퍼는 오버플로가 기존 데이터를 덮어쓰는 순환 버퍼입니다. 네트워크 카드는 전송(TX)을 할당하고(RX) 링 버퍼를 수신합니다. 수신 링 버퍼는 장치 드라이버와 NIC(네트워크 인터페이스 컨트롤러) 간에 공유됩니다. 데이터는 SoftIRQs라고도 하는 하드웨어 인터럽트 또는 소프트웨어 인터럽트를 통해 NIC에서 커널로 이동할 수 있습니다.

커널은 장치 드라이버가 이를 처리할 수 있을 때까지 RX 링 버퍼를 사용하여 들어오는 패킷을 저장합니다. 장치 드라이버는 일반적으로 SoftIRQs를 사용하여 RX 링을 드레이닝하여 들어오는 패킷을 sk_buff 또는 skb 라는 커널 데이터 구조에 배치하여 커널과 관련 소켓을 소유하는 애플리케이션까지 이동합니다.

커널은 TX 링 버퍼를 사용하여 네트워크로 전송해야 하는 발신 패킷을 보관합니다. 이러한 링 버퍼는 스택 하단에 있으며 패킷 드롭이 발생할 수 있는 중요한 지점이며 네트워크 성능에 부정적인 영향을 미칩니다.

NetworkManager 연결 프로필에서 링 버퍼 설정을 구성합니다. Ansible 및 네트워크 RHEL 시스템 역할을 사용하면 이 프로세스를 자동화하고 플레이북에 정의된 호스트에서 연결 프로필을 원격으로 구성할 수 있습니다.

주의

네트워크 RHEL 시스템 역할을 사용하여 기존 연결 프로필의 특정 값만 업데이트할 수 없습니다. 이 역할은 연결 프로필이 플레이북의 설정과 정확히 일치하는지 확인합니다. 동일한 이름의 연결 프로필이 이미 존재하는 경우 역할은 플레이북의 설정을 적용하고 프로필의 다른 모든 설정을 기본값으로 재설정합니다. 값을 재설정하지 않으려면 변경하려는 설정을 포함하여 플레이북에서 네트워크 연결 프로필의 전체 구성을 항상 지정합니다.

사전 요구 사항

  • 컨트롤 노드 및 관리형 노드를 준비했습니다.
  • 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
  • 관리 노드에 연결하는 데 사용하는 계정에는 sudo 권한이 있습니다.
  • 장치가 지원하는 최대 링 버퍼 크기를 알고 있습니다.

프로세스

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Configure the network
      hosts: managed-node-01.example.com
      tasks:
        - name: Ethernet connection profile with dynamic IP address setting and increased ring buffer sizes
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.network
          vars:
            network_connections:
              - name: enp1s0
                type: ethernet
                autoconnect: yes
                ip:
                  dhcp4: yes
                  auto6: yes
                ethtool:
                  ring:
                    rx: 4096
                    tx: 4096
                state: up
    Copy to Clipboard Toggle word wrap

    예제 플레이북에 지정된 설정은 다음과 같습니다.

    rx: <value>
    수신된 최대 링 버퍼 항목 수를 설정합니다.
    TX: &lt ;value>
    전송된 최대 링 버퍼 항목 수를 설정합니다.

    플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의 /usr/share/ansible/roles/rhel-system-roles.network/README.md 파일을 참조하십시오.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

검증

  • 최대 링 버퍼 크기를 표시합니다.

    # ansible managed-node-01.example.com -m command -a 'ethtool -g enp1s0'
    managed-node-01.example.com | CHANGED | rc=0 >>
    ...
    Current hardware settings:
    RX:             4096
    RX Mini:        0
    RX Jumbo:       0
    TX:             4096
    Copy to Clipboard Toggle word wrap

1.3. 패킷 드롭을 방지하기 위해 네트워크 장치 백로그 대기열 튜닝

네트워크 카드가 패킷을 수신할 때 커널 프로토콜 스택이 이를 처리하기 전에 커널은 이러한 패킷을 백로그 큐에 저장합니다. 커널은 각 CPU 코어에 대해 별도의 큐를 유지 관리합니다.

코어의 백로그 큐가 가득 차면 커널은 netif_receive_skb() 커널 함수가 이 큐에 할당하는 들어오는 모든 패킷을 삭제합니다. 서버에 10Gbps 또는 더 빠른 네트워크 어댑터 또는 여러 개의 1Gbps 어댑터가 포함된 경우 백로그 큐 크기를 조정하여 이 문제를 방지합니다.

사전 요구 사항

  • 10Gbps 이상 또는 여러 개의 1Gbps 네트워크 어댑터

프로세스

  1. 백로그 큐 튜닝이 필요한지 여부를 확인하고 /proc/net/softnet_stat 파일에 카운터를 표시합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
    221951548  0      0  0  0  0  0  0  0  0  0  0  0
    192058677  18862  0  0  0  0  0  0  0  0  0  0  1
    455324886  0      0  0  0  0  0  0  0  0  0  0  2
    ...
    Copy to Clipboard Toggle word wrap

    awk 명령은 /proc/net/softnet_stat 의 값을 16진수에서 10진수 형식으로 변환하고 테이블 형식으로 표시합니다. 각 행은 core 0부터 시작하는 CPU 코어를 나타냅니다.

    관련 열은 다음과 같습니다.

    • 첫 번째 열: 수신된 총 프레임 수
    • 두 번째 열: 전체 백로그 큐로 인해 삭제된 프레임 수
    • 마지막 열: CPU 코어 번호
  2. /proc/net/softnet_stat 파일의 두 번째 열에 있는 값이 시간이 지남에 따라 증가하면 백로그 큐의 크기를 늘립니다.

    1. 현재 백로그 큐 크기를 표시합니다.

      # sysctl net.core.netdev_max_backlog
      net.core.netdev_max_backlog = 1000
      Copy to Clipboard Toggle word wrap
    2. 다음 콘텐츠를 사용하여 /etc/sysctl.d/10-netdev_max_backlog.conf 파일을 만듭니다.

      net.core.netdev_max_backlog = 2000
      Copy to Clipboard Toggle word wrap

      net.core.netdev_max_backlog 매개변수를 현재 값의 double으로 설정합니다.

    3. /etc/sysctl.d/10-netdev_max_backlog.conf 파일에서 설정을 로드합니다.

      # sysctl -p /etc/sysctl.d/10-netdev_max_backlog.conf
      Copy to Clipboard Toggle word wrap

검증

  • /proc/net/softnet_stat 파일에서 두 번째 열을 모니터링합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
    Copy to Clipboard Toggle word wrap

    값이 계속 증가하는 경우 net.core.netdev_max_backlog 값을 다시 두 배로 늘립니다. 패킷 드롭 카운터가 더 이상 증가하지 않을 때까지 이 프로세스를 반복합니다.

1.4. 전송 오류 수를 줄이기 위해 NIC의 전송 큐 길이 증가

커널은 패킷을 전송하기 전에 전송 큐에 저장합니다. 기본 길이(1000 패킷)는 일반적으로 10Gbps에 충분하며 40Gbps 네트워크에도 적합합니다. 그러나 더 빠른 네트워크에서 또는 어댑터에서 전송 오류 수가 증가함에 따라 큐 길이를 늘립니다.

프로세스

  1. 현재 전송 큐 길이를 표시합니다.

    # ip -s link show enp1s0
    2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    ...
    Copy to Clipboard Toggle word wrap

    이 예에서 enp1s0 인터페이스의 전송 큐 길이는 1000 입니다.

  2. 네트워크 인터페이스의 소프트웨어 전송 대기열의 삭제된 패킷 카운터를 모니터링합니다.

    # tc -s qdisc show dev enp1s0
    qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
     Sent 16889923 bytes 426862765 pkt (dropped 191980, overlimits 0 requeues 2)
    ...
    Copy to Clipboard Toggle word wrap
  3. 높은 전송 오류 수가 발생하거나 증가하는 경우 더 높은 전송 대기열 길이를 설정합니다.

    1. 이 인터페이스를 사용하는 NetworkManager 연결 프로필을 확인합니다.

      # nmcli connection show
      NAME                UUID                                  TYPE      DEVICE
      Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0
      Copy to Clipboard Toggle word wrap
    2. 연결 프로필을 업데이트하고 전송 큐 길이를 늘립니다.

      # nmcli connection modify Example-Connection link.tx-queue-length 2000
      Copy to Clipboard Toggle word wrap

      현재 값의 큐 길이를 double로 설정합니다.

    3. 변경 사항을 적용합니다.

      # nmcli connection up Example-Connection
      Copy to Clipboard Toggle word wrap

검증

  1. 전송 큐 길이를 표시합니다.

    # ip -s link show enp1s0
    2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 2000
    ...
    Copy to Clipboard Toggle word wrap
  2. 삭제된 패킷 카운터를 모니터링합니다.

    # tc -s qdisc show dev enp1s0
    Copy to Clipboard Toggle word wrap

    드롭된 카운터가 계속 증가하면 전송 큐 길이를 다시 두 배로 늘립니다. 카운터가 더 이상 증가하지 않을 때까지 이 프로세스를 반복합니다.

!:context:

2장. IRQ 밸런싱 튜닝

멀티 코어 호스트에서 Red Hat Enterprise Linux가 인터럽트 대기열(IRQ)의 균형을 조정하여 CPU 코어에 인터럽트를 배포할 수 있도록 하여 성능을 향상시킬 수 있습니다.

2.1. 인터럽트 및 인터럽트 처리기

NIC(네트워크 인터페이스 컨트롤러)가 들어오는 데이터를 수신하면 DMA(직접 메모리 액세스)를 사용하여 데이터를 커널 버퍼에 복사합니다. 그러면 NIC에서 하드 인터럽트를 트리거하여 커널에 이 데이터에 대해 알립니다. 이러한 인터럽트는 이미 다른 작업을 중단했으며 처리기가 자체적으로 중단할 수 없으므로 최소한의 작업을 수행하는 인터럽트 처리기에 의해 처리됩니다. 하드 인터럽트는 특히 커널 잠금을 사용하는 경우 CPU 사용량 측면에서 비용이 많이 들 수 있습니다.

그런 다음 하드 인터럽트 처리기는 대부분의 패킷 수신을 소프트웨어 인터럽트 요청(SoftIRQ) 프로세스에 남겨 둡니다. 커널은 이러한 프로세스를 보다 공정하게 예약할 수 있습니다.

예 2.1. 하드웨어 인터럽트 표시

커널은 인터럽트 카운터를 /proc/interrupts 파일에 저장합니다. enp1s0 과 같은 특정 NIC의 카운터를 표시하려면 다음을 입력합니다.

# grep -E "CPU|enp1s0" /proc/interrupts
         CPU0     CPU1     CPU2    CPU3    CPU4   CPU5
 105:  141606        0        0       0       0      0  IR-PCI-MSI-edge      enp1s0-rx-0
 106:       0   141091        0       0       0      0  IR-PCI-MSI-edge      enp1s0-rx-1
 107:       2        0   163785       0       0      0  IR-PCI-MSI-edge      enp1s0-rx-2
 108:       3        0        0  194370       0      0  IR-PCI-MSI-edge      enp1s0-rx-3
 109:       0        0        0       0       0      0  IR-PCI-MSI-edge      enp1s0-tx
Copy to Clipboard Toggle word wrap

각 큐에는 첫 번째 열에 인터럽트 벡터가 있습니다. 시스템이 부팅되거나 사용자가 NIC 드라이버 모듈을 로드할 때 커널은 이러한 벡터를 초기화합니다. 각 수신(RX) 및 전송(TX) 큐에는 인터럽트가 들어오는 NIC 또는 큐를 인터럽트 처리기에 알리는 고유한 벡터가 할당됩니다. 열은 모든 CPU 코어에 대한 들어오는 인터럽트 수를 나타냅니다.

2.2. 소프트웨어 인터럽트 요청

소프트웨어 인터럽트 요청(SoftIRQs)은 네트워크 어댑터의 수신 링 버퍼를 지웁니다. 커널은 다른 작업이 중단되지 않을 때 한 번에 실행하도록 softIRQ 루틴을 예약합니다. Red Hat Enterprise Linux에서 ksoftirqd/cpu-number 라는 프로세스는 이러한 루틴을 실행하고 드라이버별 코드 기능을 호출합니다.

각 CPU 코어에 대한 SoftIRQ 카운터를 모니터링하려면 다음을 입력합니다.

# watch -n1 'grep -E "CPU|NET_RX|NET_TX" /proc/softirqs'
                    CPU0       CPU1	  CPU2       CPU3	CPU4	   CPU5       CPU6	 CPU7
      NET_TX:	   49672      52610	 28175      97288      12633	  19843      18746     220689
      NET_RX:         96       1615        789         46         31	   1735       1315     470798
Copy to Clipboard Toggle word wrap

명령은 출력을 동적으로 업데이트합니다. Ctrl+C 눌러 출력을 중단합니다.

2.3. NAPI Polling

새로운 API(NAPI)는 들어오는 네트워크 패킷의 효율성을 개선하기 위한 장치 드라이버 패킷 처리 프레임워크의 확장입니다. 하드 인터럽트는 일반적으로 커널 공간에서 사용자 공간으로 컨텍스트 전환을 유발하고 다시 중단시킬 수 없기 때문에 비용이 많이 듭니다. 인터럽트 병합에도 불구하고 인터럽트 처리기는 CPU 코어를 완전히 독점합니다. NAPI를 사용하면 드라이버가 수신되는 모든 패킷에 대해 커널에 의해 중단되는 대신 폴링 모드를 사용할 수 있습니다.

정상적인 작동에서 커널은 초기 하드 인터럽트를 실행한 다음 NAPI 루틴을 사용하여 네트워크 카드를 폴링하는 소프트 인터럽트 요청(SoftIRQ) 핸들러를 발행합니다. SoftIRQ가 CPU 코어를 단조하는 것을 방지하기 위해 폴링 루틴은 SoftIRQ에서 사용할 수 있는 CPU 시간을 결정하는 예산을 갖습니다. SoftIRQ 폴링 루틴이 완료되면 커널은 루틴을 종료하고 나중에 다시 실행하도록 스케줄링하여 네트워크 카드에서 패킷을 수신하는 프로세스를 반복합니다.

2.4. irqbalance 서비스

NUMA(Non-Uniform Memory Access) 아키텍처가 있고 없는 시스템에서 irqbalance 서비스는 시스템 조건에 따라 CPU 코어 간에 인터럽트를 효과적으로 조정합니다. irqbalance 서비스는 백그라운드에서 실행되며 10초마다 CPU 부하를 모니터링합니다. CPU 부하가 너무 높은 경우 서비스는 인터럽트를 다른 CPU 코어로 이동합니다. 결과적으로 시스템이 잘 작동하고 부하를 더 효율적으로 처리합니다.

irqbalance 가 실행 중이 아닌 경우 일반적으로 CPU 코어 0은 대부분의 인터럽트를 처리합니다. 중간 부하가 있더라도 이 CPU 코어는 시스템에 있는 모든 하드웨어의 워크로드를 처리하려고 할 수 있습니다. 결과적으로 인터럽트 또는 인터럽트 기반 작업을 누락하거나 지연할 수 있습니다. 이로 인해 네트워크 및 스토리지 성능, 패킷 손실 및 잠재적으로 기타 문제가 발생할 수 있습니다.

중요

irqbalance 를 비활성화하면 네트워크 처리량에 부정적인 영향을 미칠 수 있습니다.

단일 CPU 코어만 있는 시스템에서 irqbalance 서비스는 아무런 이점도 제공하지 않고 자체적으로 종료됩니다.

기본적으로 irqbalance 서비스는 Red Hat Enterprise Linux에서 활성화되어 실행됩니다. 서비스를 비활성화한 경우 서비스를 다시 활성화하려면 다음을 입력합니다.

# systemctl enable --now irqbalance
Copy to Clipboard Toggle word wrap

2.5. CPU에서 SoftIRQs를 실행할 수 있는 시간 증가

SoftIRQ가 충분히 오래 실행되지 않으면 들어오는 데이터의 속도가 버퍼를 충분히 빨리 드레이닝하는 커널의 기능을 초과할 수 있습니다. 결과적으로 NIC(네트워크 인터페이스 컨트롤러) 버퍼 오버플로 및 패킷이 손실됩니다.

softirqd 프로세스에서 하나의 NAPI 폴링 주기의 인터페이스에서 모든 패킷을 검색할 수 없는 경우 SoftIRQ에 충분한 CPU 시간이 없다는 것을 나타냅니다. 이는 빠른 NIC가 있는 호스트의 경우(예: 10Gbps 이상)일 수 있습니다. net.core.netdev_budgetnet.core.netdev_budget_usecs 커널 매개변수의 값을 늘리면 softirqd 가 폴링 주기에서 처리할 수 있는 시간 및 수를 제어할 수 있습니다.

프로세스

  1. net.core.netdev_budget 매개변수를 튜닝해야 하는지 확인하려면 /proc/net/softnet_stat 파일에 카운터를 표시합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
    221951548  0  0      0  0  0  0  0  0  0  0  0  0
    192058677  0  20380  0  0  0  0  0  0  0  0  0  1
    455324886  0  0      0  0  0  0  0  0  0  0  0  2
    ...
    Copy to Clipboard Toggle word wrap

    awk 명령은 /proc/net/softnet_stat 의 값을 16진수 형식에서 10진수 형식으로 변환하고 테이블 형식으로 표시합니다. 각 행은 core 0부터 시작하는 CPU 코어를 나타냅니다.

    관련 열은 다음과 같습니다.

    • 첫 번째 열: 수신된 총 프레임 수입니다.
    • 세 번째 열: 하나의 NAPI 폴링 주기로 인터페이스에서 모든 패킷을 검색할 수 없는 소프트irqd 프로세스 수입니다.
    • 마지막 열: CPU 코어 번호입니다.
  2. /proc/net/softnet_stat 파일의 세 번째 열에 있는 카운터가 시간에 따라 증가하면 시스템을 조정합니다.

    1. net.core.netdev_budget_usecsnet.core.netdev_budget 매개변수의 현재 값을 표시합니다.

      # sysctl net.core.netdev_budget_usecs net.core.netdev_budget
      net.core.netdev_budget_usecs = 2000
      net.core.netdev_budget = 300
      Copy to Clipboard Toggle word wrap

      이러한 설정을 사용하면 softirqd 프로세스는 NIC에서 최대 300개의 메시지를 하나의 폴링 주기로 처리할 수 있도록 최대 2000 마이크로초까지 사용할 수 있습니다. 폴링은 가장 먼저 충족되는 조건에 따라 종료됩니다.

    2. 다음 콘텐츠를 사용하여 /etc/sysctl.d/10-netdev_budget.conf 파일을 만듭니다.

      net.core.netdev_budget = 600
      net.core.netdev_budget_usecs = 4000
      Copy to Clipboard Toggle word wrap

      매개 변수를 현재 값의 이중으로 설정합니다.

    3. /etc/sysctl.d/10-netdev_budget.conf 파일에서 설정을 로드합니다.

      # sysctl -p /etc/sysctl.d/10-netdev_budget.conf
      Copy to Clipboard Toggle word wrap

검증

  • /proc/net/softnet_stat 파일에서 세 번째 열을 모니터링합니다.

    # awk '{for (i=1; i<=NF; i++) printf strtonum("0x" $i) (i==NF?"\n":" ")}' /proc/net/softnet_stat | column -t
    Copy to Clipboard Toggle word wrap

    값이 계속 증가하는 경우 net.core.netdev_budget_usecsnet.core.netdev_budget 를 더 높은 값으로 설정합니다. 카운터가 더 이상 증가하지 않을 때까지 이 프로세스를 반복합니다.

3장. 네트워크 대기 시간 개선

CPU 전원 관리 기능으로 인해 시간에 민감한 애플리케이션 처리 시 원치 않는 지연이 발생할 수 있습니다. 이러한 전원 관리 기능의 일부 또는 모두를 비활성화하여 네트워크 대기 시간을 개선할 수 있습니다.

예를 들어 서버가 과도한 부하보다 유휴 상태일 때 대기 시간이 길면 CPU 전원 관리 설정이 대기 시간에 영향을 미칠 수 있습니다.

중요

CPU 전원 관리 기능을 비활성화하면 전력 소비와 열 손실이 증가할 수 있습니다.

3.1. CPU 전원 상태가 네트워크 대기 시간에 미치는 영향

CPU의 사용 상태(C-상태)는 컴퓨터의 전력 소비를 최적화하고 줄입니다. C-states는 C0부터 번호가 지정됩니다. C0에서는 프로세서의 전원이 완전히 실행되고 있습니다. C1에서는 프로세서의 전원이 완전히 작동하지만 실행되지 않습니다. C-state 수가 많을수록 CPU가 꺼질수록 구성 요소가 증가합니다.

CPU 코어가 유휴 상태가 될 때마다 기본 제공 전원 저장 논리 단계 및 다양한 프로세서 구성 요소를 비활성화하여 현재 C-state에서 더 높은 코어로 코어를 이동하려고 합니다. CPU 코어가 데이터를 처리해야 하는 경우 RHEL(Red Hat Enterprise Linux)은 프로세서에 인터럽트를 전송하여 코어를 중단하고 C-state를 다시 C0으로 설정합니다.

C-states에서 C0으로 다시 전환하려면 프로세서의 다양한 구성 요소로 다시 전원을 켜기 때문에 시간이 걸립니다. 멀티 코어 시스템에서는 여러 코어가 동시에 유휴 상태이므로 더 깊은 C 상태에서도 발생할 수 있습니다. RHEL이 이를 동시에 발생시키려면 커널은 많은 수의 IPI(Inter-Processor Interrupts)를 생성하고 모든 코어는 C-state에서 반환될 수 있습니다. 인터럽트를 처리하는 동안 필요한 잠금으로 인해 시스템은 모든 인터럽트를 처리하는 동안 잠시 중단될 수 있습니다. 이로 인해 이벤트에 대한 애플리케이션 응답이 지연될 수 있습니다.

예 3.1. 코어당 C-state의 시간 표시

PowerTOP 애플리케이션의 Idle Stats 페이지는 각 C-state에서 CPU 코어가 소비하는 시간을 표시합니다.

           Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 4
                    |                     | C0 active   2.5%        2.2%
                    |                     | POLL        0.0%    0.0 ms  0.0%    0.1 ms
                    |                     | C1          0.1%    0.2 ms  0.0%    0.1 ms
C2 (pc2)   63.7%    |                     |
C3 (pc3)    0.0%    | C3 (cc3)    0.1%    | C3          0.1%    0.1 ms  0.1%    0.1 ms
C6 (pc6)    0.0%    | C6 (cc6)    8.3%    | C6          5.2%    0.6 ms  6.0%    0.6 ms
C7 (pc7)    0.0%    | C7 (cc7)   76.6%    | C7s         0.0%    0.0 ms  0.0%    0.0 ms
C8 (pc8)    0.0%    |                     | C8          6.3%    0.9 ms  5.8%    0.8 ms
C9 (pc9)    0.0%    |                     | C9          0.4%    3.7 ms  2.2%    2.2 ms
C10 (pc10)  0.0%    |                     |
                    |                     | C10        80.8%    3.7 ms 79.4%    4.4 ms
                    |                     | C1E         0.1%    0.1 ms  0.1%    0.1 ms
...
Copy to Clipboard Toggle word wrap

3.2. EFI 펌웨어의 C-state 설정

EFI 펌웨어가 있는 대부분의 시스템에서는 개별 사용 상태(C-state)를 활성화하고 비활성화할 수 있습니다. 그러나 RHEL(Red Hat Enterprise Linux)에서 유휴 드라이버는 커널이 펌웨어의 설정을 사용하는지 여부를 결정합니다.

  • intel_idle: Intel CPU가 있는 호스트의 기본 드라이버이며 EFI 펌웨어의 C-state 설정을 무시합니다.
  • acpi_idle: RHEL은 Intel 이외의 공급업체의 CPU가 있고 intel_idle 이 비활성화된 경우 호스트에서 이 드라이버를 사용합니다. 기본적으로 acpi_idle 드라이버는 EFI 펌웨어의 C-state 설정을 사용합니다.

자세한 내용은 kernel-doc 패키지에서 제공하는 /usr/share/doc/kernel-doc- <version> /Documentation/admin-guide/pm/cpuidle.rst 파일을 참조하십시오.

3.3. 사용자 정의 TuneD 프로필을 사용하여 C 상태 비활성화

TuneD 서비스는 커널의PMQOS(Power Management Quality of Service) 인터페이스를 사용하여 소비 상태(C-states) 잠금을 설정합니다. 커널 유휴 드라이버는 이 인터페이스와 통신하여 C-state를 동적으로 제한할 수 있습니다. 이렇게 하면 관리자가 커널 명령줄 매개 변수를 사용하여 최대 C-state 값을 하드 코딩해야 합니다.

사전 요구 사항

  • tuned 패키지가 설치되어 있습니다.
  • tuned 서비스가 활성화되어 실행 중입니다.

프로세스

  1. 활성 프로필을 표시합니다.

    # tuned-adm active
    Current active profile: network-latency
    Copy to Clipboard Toggle word wrap
  2. 사용자 지정 TuneD 프로필에 대한 디렉터리를 생성합니다.

    # mkdir /etc/tuned/network-latency-custom/
    Copy to Clipboard Toggle word wrap
  3. 다음 콘텐츠를 사용하여 /etc/tuned/network-latency-custom/tuned.conf 파일을 만듭니다.

    [main]
    include=network-latency
    
    [cpu]
    force_latency=cstate.id:1|2
    Copy to Clipboard Toggle word wrap

    이 사용자 지정 프로필은 network-latency 프로필의 모든 설정을 상속합니다. force_latency TuneD 매개변수는 microseconds( Cryostat)로 대기 시간을 지정합니다. C-state latency가 지정된 값보다 크면 Red Hat Enterprise Linux의 유휴 드라이버를 사용하면 CPU가 더 높은 C-state로 이동하지 못합니다. force_latency=cstate.id:1|2 를 사용하면 TuneD에서 먼저 /sys/devices/system/cpu/cpu_<number>_/cpuidle/state_<cstate.id>_/ 디렉터리가 있는지 확인합니다. 이 경우 TuneD는 이 디렉터리의 대기 시간 파일에서 latency 값을 읽습니다. 디렉터리가 없는 경우 TuneD는 폴백 값으로 2마이크로초를 사용합니다.

  4. network-latency-custom 프로필을 활성화합니다.

    # tuned-adm profile network-latency-custom
    Copy to Clipboard Toggle word wrap

3.4. 커널 명령줄 옵션을 사용하여 C-state 비활성화

processor.max_cstateintel_idle.max_cstate 커널 명령줄 매개변수는 C-state에서 사용할 수 있는 최대 사용 상태(C-state)를 구성합니다. 예를 들어 매개 변수를 1 로 설정하면 CPU가 C1 미만의 C-state를 요청하지 않습니다.

이 방법을 사용하여 호스트에서 애플리케이션의 대기 시간이 C-states의 영향을 받는지 여부를 테스트합니다. 특정 상태를 하드 코딩하지 않으려면 더 동적 솔루션을 사용하는 것이 좋습니다. 사용자 정의 TuneD 프로필을 사용하여 C 상태 비활성화를 참조하십시오.

사전 요구 사항

  • tuned 서비스는 C-state 설정을 업데이트하지 않도록 실행 중이거나 구성되지 않았습니다.

프로세스

  1. 시스템이 사용하는 유휴 드라이버를 표시합니다.

    # cat /sys/devices/system/cpu/cpuidle/current_driver
    intel_idle
    Copy to Clipboard Toggle word wrap

    드라이버에 대한 자세한 내용은 kernel-doc 패키지에서 제공하는 /usr/share/doc/kernel-doc- <version> /Documentation/admin-guide/pm/cpuidle.rst 파일을 참조하십시오.

  2. 호스트가 intel_idle 드라이버를 사용하는 경우 intel_idle.max_cstate 커널 매개변수를 설정하여 CPU 코어가 사용할 수 있는 가장 높은 C-state를 정의합니다.

    # grubby --update-kernel=ALL --args="intel_idle.max_cstate=0"
    Copy to Clipboard Toggle word wrap

    intel_idle.max_cstate=0 을 설정하면 intel_idle 드라이버가 비활성화됩니다. 결과적으로 커널은 EFI 펌웨어에 설정된 C-state 값을 사용하는 acpi_idle 드라이버를 사용합니다. 이러한 이유로 이러한 C 상태 설정을 재정의하도록 processor.max_cstate 도 설정합니다.

  3. CPU 벤더와 무관하게 모든 호스트에서 CPU 코어를 사용할 수 있는 가장 높은 C-state를 설정합니다.

    # grubby --update-kernel=ALL --args="processor.max_cstate=0"
    Copy to Clipboard Toggle word wrap
    중요

    intel_idle.max_cstate=0 외에도 processor.max_cstate=0 을 설정하면 acpi_idle 드라이버가 processor.max_cstate 의 값을 재정의하고 1 로 설정합니다. 결과적으로 processor.max_cstate=0 intel_idle.max_cstate=0 을 사용하면 커널이 C0이 아닌 C-state가 가장 높습니다.

  4. 변경 사항을 적용하려면 호스트를 다시 시작하십시오.

    # reboot
    Copy to Clipboard Toggle word wrap

검증

  1. 최대 C-state를 표시합니다.

    # cat /sys/module/processor/parameters/max_cstate
    1
    Copy to Clipboard Toggle word wrap
  2. 호스트가 intel_idle 드라이버를 사용하는 경우 최대 C-state를 표시합니다.

    # cat /sys/module/intel_idle/parameters/max_cstate
    0
    Copy to Clipboard Toggle word wrap

4장. 많은 양의 연속 데이터 스트림의 처리량 개선

IEEE 802.3 표준에 따르면 VLAN(Virtual Local Area Network) 태그가 없는 기본 이더넷 프레임의 최대 크기는 1518바이트입니다. 이러한 프레임 각각은 18바이트 헤더를 포함하며 페이로드를 위해 1500바이트를 남겨 둡니다. 그 결과, 1500바이트의 데이터마다 서버가 네트워크를 통해 전송되는 경우 18바이트(1.2%) 이더넷 프레임 헤더도 오버헤드로 전송되고 전송됩니다. 계층 3 및 4 프로토콜의 헤더는 패킷당 오버헤드를 추가로 늘립니다.

네트워크의 호스트가 백업 서버 또는 다수의 대용량 파일을 호스팅하는 파일 서버와 같은 여러 연속 데이터 스트림을 보내는 경우 점보 프레임을 사용하여 오버헤드를 줄이는 것이 좋습니다. 점보 프레임은 1500바이트의 표준 이더넷 페이로드 크기보다 더 큰 최대 전송 단위(MTU)가 있는 비표준 프레임입니다. 예를 들어 허용되는 최대 MTU가 9000바이트 페이로드인 점보 프레임을 구성하는 경우 각 프레임의 오버헤드가 0.2%로 줄어듭니다.

네트워크 및 서비스에 따라 클러스터의 스토리지 백엔드와 같은 네트워크의 특정 부분에서만 점보 프레임을 활성화하는 것이 좋습니다. 이렇게 하면 패킷 조각화를 방지할 수 있습니다.

4.1. 점보 프레임을 구성하기 전에 고려 사항

네트워크의 하드웨어, 애플리케이션 및 서비스에 따라 점보 프레임이 다른 영향을 미칠 수 있습니다. 점보 프레임 활성화가 시나리오에서 이점을 제공하는지 여부를 신중하게 결정합니다.

점보 프레임에 대한 사전 요구 사항:

전송 경로의 모든 네트워크 장치는 점보 프레임을 지원해야 하며 동일한 최대 전송 단위(MTU) 크기를 사용해야 합니다. 반대의 경우 다음과 같은 문제에 직면할 수 있습니다.

  • 패키지를 삭제했습니다.
  • 조각화된 패킷 때문에 대기 시간이 길어집니다.
  • 조각화로 인한 패킷 손실의 위험이 증가했습니다. 예를 들어 라우터가 단일 9000바이트 프레임을 6 1500바이트 프레임으로 조각화하고 해당 1500바이트 프레임 중 하나가 손실되면 재 조립할 수 없기 때문에 전체 프레임이 손실됩니다.

다음 다이어그램에서 네트워크 A의 호스트가 네트워크 C의 호스트로 패킷을 보내는 경우 세 서브넷의 모든 호스트에서 동일한 MTU를 사용해야 합니다.

network diagram MTU

점보 프레임의 이점:

  • 처리량 증가: 프로토콜 오버헤드가 고정된 동안 각 프레임에는 더 많은 사용자 데이터가 포함됩니다.
  • CPU 사용률 감소: 점보 프레임으로 인해 인터럽트 수가 줄어들고 CPU 사이클이 저장됩니다.

점보 프레임의 단점:

  • 높은 대기 시간: 많은 프레임이 후속 패킷을 지연합니다.
  • 메모리 버퍼 사용량 증가: 큰 프레임은 버퍼 큐 메모리를 더 빠르게 채울 수 있습니다.

4.2. 기존 NetworkManager 연결 프로필에서 MTU 구성

네트워크에 기본값과 다른 최대 전송 단위(MTU)가 필요한 경우 해당 NetworkManager 연결 프로필에서 이 설정을 구성할 수 있습니다.

점보 프레임은 1500바이트에서 9000바이트 사이의 페이로드가 있는 네트워크 패킷입니다. 동일한 브로드캐스트 도메인에 있는 모든 장치는 이러한 프레임을 지원해야 합니다.

사전 요구 사항

  • 브로드캐스트 도메인의 모든 장치는 동일한 MTU를 사용합니다.
  • 네트워크의 MTU를 알고 있습니다.
  • divergent MTU를 사용하여 네트워크에 대한 연결 프로필을 이미 구성하셨습니다.

프로세스

  1. 선택 사항: 현재 MTU를 표시합니다.

    # ip link show
    ...
    3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    ...
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: NetworkManager 연결 프로필을 표시합니다.

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    Example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
    ...
    Copy to Clipboard Toggle word wrap
  3. 다양한 MTU를 사용하여 네트워크 연결을 관리하는 프로필에서 MTU를 설정합니다.

    # nmcli connection modify Example mtu 9000
    Copy to Clipboard Toggle word wrap
  4. 연결을 다시 활성화합니다.

    # nmcli connection up Example
    Copy to Clipboard Toggle word wrap

검증

  1. MTU 설정을 표시합니다.

    # ip link show
    ...
    3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    ...
    Copy to Clipboard Toggle word wrap
  2. 전송 경로의 호스트가 패킷을 조각화하지 않는지 확인합니다.

    • 수신자 측에서 커널의 IP 재 조립 통계를 표시합니다.

      # nstat -az IpReasm*
      #kernel
      IpReasmTimeout 0 0.0
      IpReasmReqds 0 0.0
      IpReasmOKs 0 0.0
      IpReasmFails 0 0.0
      Copy to Clipboard Toggle word wrap

      카운터가 0 을 반환하면 패킷을 다시 조립하지 않았습니다.

    • 보낸 사람 측에서 prohibit-fragmentation-bit를 사용하여 ICMP 요청을 전송합니다.

      # ping -c1 -Mdo -s 8972 destination_host
      Copy to Clipboard Toggle word wrap

      명령이 성공하면 패킷이 조각화되지 않았습니다.

      다음과 같이 -s 패킷 크기 옵션의 값을 계산합니다. MTU 크기 - 8바이트 ICMP 헤더 - 20바이트 IPv4 헤더 = 패킷 크기

5장. 처리량이 높은 TCP 연결 튜닝

Red Hat Enterprise Linux에서 TCP 관련 설정을 조정하여 처리량을 늘리거나 대기 시간을 줄이거나 패킷 손실과 같은 문제를 방지합니다.

5.1. iperf3을 사용하여 TCP 처리량 테스트

iperf3 유틸리티는 두 호스트 간에 네트워크 처리량 테스트를 수행하는 서버와 클라이언트 모드를 제공합니다.

참고

애플리케이션의 처리량은 애플리케이션에서 사용하는 버퍼 크기와 같은 여러 요인에 따라 달라집니다. 따라서 iperf3 과 같은 테스트 유틸리티로 측정된 결과는 프로덕션 워크로드가 있는 서버의 애플리케이션과 크게 다를 수 있습니다.

사전 요구 사항

  • iperf3 패키지는 클라이언트와 서버 둘 다에 설치됩니다.
  • 어느 호스트의 다른 서비스는 테스트 결과에 상당한 영향을 미치는 네트워크 트래픽을 유발하지 않습니다.
  • 40Gbps 및 빠른 연결의 경우 네트워크 카드는 가속 Receive Flow Steering (ARFS)을 지원하며 인터페이스에서 기능이 활성화됩니다.

프로세스

  1. 선택 사항: 서버와 클라이언트 모두에서 NIC(네트워크 인터페이스 컨트롤러)의 최대 네트워크 속도를 표시합니다.

    # ethtool enp1s0 | grep "Speed"
       Speed: 100000Mb/s
    Copy to Clipboard Toggle word wrap
  2. 서버에서 다음을 수행합니다.

    1. firewalld 서비스에서 기본 iperf3 TCP 포트 5201을 일시적으로 엽니다.

      # firewall-cmd --add-port=5201/tcp
      Copy to Clipboard Toggle word wrap
    2. 서버 모드에서 iperf3 을 시작합니다.

      # iperf3 --server
      Copy to Clipboard Toggle word wrap

      이제 서비스가 들어오는 클라이언트 연결을 대기 중입니다.

  3. 클라이언트에서 다음을 수행합니다.

    1. 처리량 측정을 시작합니다.

      # iperf3 --time 60 --zerocopy --client 192.0.2.1
      Copy to Clipboard Toggle word wrap
      • --time <seconds > : 클라이언트가 전송을 중지한 시간을 초 단위로 정의합니다.

        이 매개변수를 작업할 것으로 예상되는 값으로 설정하고 이후 측정에서 늘립니다. 클라이언트가 전송 경로의 장치보다 빠른 속도로 패킷을 종료하거나 서버에서 처리할 수 있는 경우 패킷을 삭제할 수 있습니다.

      • --zerocopy: write() 시스템 호출을 사용하는 대신 0 복사 메서드를 활성화합니다. 이 옵션은 제로 복사 가능 애플리케이션을 시뮬레이션하거나 단일 스트림에서 40Gbps 이상을 달성하려는 경우에만 필요합니다.
      • --client <server >: 클라이언트 모드를 활성화하고 iperf3 서버를 실행하는 서버의 IP 주소 또는 이름을 설정합니다.
  4. iperf3 이 테스트를 완료할 때까지 기다립니다. 서버와 클라이언트 모두 통계를 1초마다 표시하고 마지막에 요약을 표시합니다. 예를 들어 다음은 클라이언트에 표시되는 요약입니다.

    [ ID] Interval         Transfer    Bitrate         Retr
    [  5] 0.00-60.00  sec  101 GBytes   14.4 Gbits/sec   0   sender
    [  5] 0.00-60.04  sec  101 GBytes   14.4 Gbits/sec       receiver
    Copy to Clipboard Toggle word wrap

    이 예에서 평균 비트레이트는 14.4Gbps입니다.

  5. 서버에서 다음을 수행합니다.

    1. Ctrl+C 눌러 iperf3 서버를 중지합니다.
    2. firewalld 에서 TCP 포트 5201을 닫습니다.

      # firewall-cmd --remove-port=5201/tcp
      Copy to Clipboard Toggle word wrap

5.2. 시스템 전체 TCP 소켓 버퍼 설정

소켓 버퍼는 커널이 수신했거나 보내야 하는 데이터를 일시적으로 저장합니다.

  • 읽기 소켓 버퍼는 커널이 수신했지만 애플리케이션을 아직 읽지 않은 패킷을 보유합니다.
  • 쓰기 소켓 버퍼는 애플리케이션이 버퍼에 기록했지만 커널이 아직 IP 스택 및 네트워크 드라이버에 전달되지 않은 패킷을 보유합니다.

TCP 패킷이 너무 커서 버퍼 크기 또는 패킷이 너무 빠른 속도로 전송 또는 수신되는 경우 커널은 데이터가 버퍼에서 제거될 때까지 새로운 들어오는 TCP 패킷을 삭제합니다. 이 경우 소켓 버퍼를 늘리면 패킷 손실을 방지할 수 있습니다.

net.ipv4.tcp_rmem (read) 및 net.ipv4.tcp_wmem (write) 소켓 버퍼 설정에는 다음 세 가지 값이 포함됩니다.

net.ipv4.tcp_rmem = 4096  131072  6291456
net.ipv4.tcp_wmem = 4096  16384   4194304
Copy to Clipboard Toggle word wrap

표시된 값은 바이트 단위이며 Red Hat Enterprise Linux는 다음과 같은 방식으로 사용합니다.

  • 첫 번째 값은 최소 버퍼 크기입니다. 새 소켓은 더 작은 크기를 가질 수 없습니다.
  • 두 번째 값은 기본 버퍼 크기입니다. 애플리케이션이 버퍼 크기를 설정하지 않으면 기본값입니다.
  • 세 번째 값은 자동으로 tuned 버퍼의 최대 크기입니다. 애플리케이션에서 SO_SNDBUF 소켓 옵션과 함께 setsockopt() 함수를 사용하면 이 최대 버퍼 크기가 비활성화됩니다.

net.ipv4.tcp_rmemnet.ipv4.tcp_wmem 매개 변수는 IPv4 및 IPv6 프로토콜 모두에 대한 소켓 크기를 설정합니다.

5.3. 시스템 전체 TCP 소켓 버퍼 증가

시스템 전체 TCP 소켓 버퍼는 커널이 수신하거나 보내야 하는 데이터를 일시적으로 저장합니다. net.ipv4.tcp_rmem (read) 및 net.ipv4.tcp_wmem (write) 소켓 커널 설정에는 각각 최소, 기본값, 최대값의 세 가지 설정이 포함됩니다.

중요

너무 큰 버퍼 크기를 설정하면 메모리가 낭비됩니다. 각 소켓은 애플리케이션 요청 크기로 설정할 수 있으며 커널은 이 값을 두 배로 늘립니다. 예를 들어, 애플리케이션이 256KiB 소켓 버퍼 크기를 요청하고 1백만 개의 소켓을 여는 경우 시스템은 잠재적인 소켓 버퍼 공간에 대해서만 최대 512GB RAM(512 KiB x 1KiB)을 사용할 수 있습니다.

또한 최대 버퍼 크기에 대한 값이 너무 크면 대기 시간이 증가할 수 있습니다.

사전 요구 사항

  • 삭제된 TCP 패킷의 비율이 크게 발생했습니다.

프로세스

  1. 연결의 대기 시간을 확인합니다. 예를 들어 클라이언트에서 서버로 ping하여 평균 RTT(Round Trip Time)를 측정합니다.

    # ping -c 10 server.example.com
    ...
    --- server.example.com ping statistics ---
    10 packets transmitted, 10 received, 0% packet loss, time 9014ms
    rtt min/avg/max/mdev = 17.208/17.056/19.333/0.616 ms
    Copy to Clipboard Toggle word wrap

    이 예에서 대기 시간은 17ms입니다.

  2. 다음 공식을 사용하여 튜닝하려는 트래픽에 대한 BDP(Bandwidth Delay Product)를 계산합니다.

    connection speed in bytes * latency in seconds = BDP in bytes
    Copy to Clipboard Toggle word wrap

    예를 들어 17ms 대기 시간이 있는 10Gbps 연결에 대한 BDP를 계산하려면 다음을 수행합니다.

    (10 * 1000 * 1000 * 1000 / 8) * 0.017 = 21,250,000 bytes
    Copy to Clipboard Toggle word wrap
  3. 요구 사항에 따라 /etc/sysctl.d/10-tcp-socket-buffers.conf 파일을 생성하고 최대 읽기 또는 쓰기 버퍼 크기를 설정하거나 둘 다 설정합니다.

    net.ipv4.tcp_rmem = 4096 262144 42500000
    net.ipv4.tcp_wmem = 4096 262144 42500000
    Copy to Clipboard Toggle word wrap

    값을 바이트 단위로 지정합니다. 환경에 최적화된 값을 식별하려는 경우 다음과 같은 지문 규칙을 사용합니다.

    • 기본 버퍼 크기(초 값): 이 값을 약간만 늘리거나 최대 524288 (512 KiB)으로 설정합니다. 기본 버퍼 크기가 너무 많으면 버퍼 축소가 발생할 수 있으며 결과적으로 대기 시간이 급증할 수 있습니다.
    • 최대 버퍼 크기(세 번째 값): BDP의 이중에서 3배가 충분한 경우가 많습니다.
  4. /etc/sysctl.d/10-tcp-socket-buffers.conf 파일에서 설정을 로드합니다.

    # sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.conf
    Copy to Clipboard Toggle word wrap
  5. net.ipv4.tcp_rmem 또는 net.ipv4.tcp_wmem 매개변수에서 두 번째 값을 변경한 경우 애플리케이션을 다시 시작하여 새 TCP 버퍼 크기를 사용합니다.

    세 번째 값만 변경한 경우 자동 조정이 동적으로 적용되므로 애플리케이션을 다시 시작할 필요가 없습니다.

검증

  1. 선택 사항: iperf3을 사용하여 TCP 처리량을 테스트합니다.
  2. 패킷이 삭제될 때 사용한 것과 동일한 방법을 사용하여 패킷 드롭 통계를 모니터링합니다.

    패킷이 계속 감소하지만 더 낮은 속도로 발생하는 경우 버퍼 크기를 더 늘립니다.

5.4. TCP 창 확장

Red Hat Enterprise Linux에서 기본적으로 활성화되어 있는 TCP 창 확장 기능은 처리량을 크게 개선하는 TCP 프로토콜의 확장입니다.

예를 들어, 1.5ms Round Trip Time(RTT)과 1Gbps 연결입니다.

  • TCP Window Scaling이 활성화된 경우 약 630Mbps의 비현실적입니다.
  • TCP 창 확장 기능을 비활성화하면 처리량이 380Mbps로 줄어듭니다.

TCP에서 제공하는 기능 중 하나는 흐름 제어입니다. 흐름 제어를 사용하면 발신자는 수신자가 수신할 수 있지만 더 이상 데이터를 보낼 수 없습니다. 이를 위해 수신자는 보낸 사람이 보낼 수 있는 데이터의 양에 해당하는 값을 알립니다.

원래 TCP는 64KiB까지 지원되지만 BDP(Bandwidth Delay Products)가 높은 경우 이 값은 발신자가 한 번에 64KiB 이상을 보낼 수 없기 때문에 제한이 됩니다. 고속 연결은 주어진 시간에 64KiB 이상의 데이터를 전송할 수 있습니다. 예를 들어 시스템 간 1밀리초의 대기 시간이 있는 10Gbps 링크의 경우 지정된 시간에 1MiB 이상의 데이터가 전송될 수 있습니다. 호스트가 64KiB만 보낸 경우 다른 호스트가 64KiB를 수신할 때까지 일시 중지하면 비효율적입니다.

이 병목 현상을 제거하기 위해 TCP 창 확장 기능을 사용하면 TCP 창 값을 연산적으로 이동하여 창 크기를 64KiB 이상으로 늘릴 수 있습니다. 예를 들어 65535 의 가장 큰 창 값이 7자리를 왼쪽으로 이동하여 창 크기가 거의 8MiB로 변경되었습니다. 이는 주어진 시간에 훨씬 더 많은 데이터를 전송할 수 있습니다.

TCP 창 확장은 모든 TCP 연결을 여는 3방향 TCP 핸드셰이크 중에 협상됩니다. 발신자와 수신자 모두 기능이 작동하려면 TCP 창 확장을 지원해야 합니다. 두 참가자 중 하나 또는 둘 다 핸드셰이크에서 창 확장 기능을 알리지 않으면 연결은 원래 16비트 TCP 창 크기를 사용하여 되돌립니다.

기본적으로 TCP 창 확장은 Red Hat Enterprise Linux에서 활성화됩니다.

# sysctl net.ipv4.tcp_window_scaling
net.ipv4.tcp_window_scaling = 1
Copy to Clipboard Toggle word wrap

서버의 TCP Window Scaling이 비활성화(0)인 경우 설정을 설정한 것과 동일한 방식으로 되돌립니다.

5.5. TCP SACK으로 패킷 드롭 속도를 줄이는 방법

RHEL(Red Hat Enterprise Linux)에서 기본적으로 활성화되어 있는 TCP SACK(TCP 선택 승인) 기능은 TCP 프로토콜을 개선하여 TCP 연결의 효율성을 높입니다.

TCP 전송에서 수신자는 수신하는 모든 패킷에 대해 발신자에게 ACK 패킷을 보냅니다. 예를 들어 클라이언트는 TCP 패킷 1-10을 서버로 전송하지만 패킷 번호 5 및 6은 손실됩니다. TCP SACK이 없으면 서버가 패킷 7-10을 삭제하고 클라이언트는 손실 시점에서 모든 패킷을 다시 전송해야 하므로 비효율적입니다. 두 호스트 모두에서 TCP SACK이 활성화된 경우 클라이언트는 손실된 패킷 5와 6만 다시 전송해야 합니다.

중요

TCP SACK을 비활성화하면 성능이 저하되고 TCP 연결의 수신자 측의 패킷 드롭율이 높아집니다.

기본적으로 TCP SACK은 RHEL에서 활성화됩니다. 확인하려면 다음을 수행합니다.

# sysctl net.ipv4.tcp_sack
1
Copy to Clipboard Toggle word wrap

서버에서 TCP SACK을 비활성화(0)하는 경우 설정을 설정하는 것과 동일한 방식으로 설정을 되돌립니다.

6장. UDP 연결 튜닝

UDP 트래픽의 처리량을 개선하기 위해 Red Hat Enterprise Linux 튜닝을 시작하기 전에 비현실적인 기대치를 갖는 것이 중요합니다. UDP는 간단한 프로토콜입니다. TCP와 비교하여 UDP에는 흐름 제어, 혼잡 제어 및 데이터 안정성과 같은 기능이 포함되어 있지 않습니다. 이로 인해 NIC(네트워크 인터페이스 컨트롤러)의 최대 속도와 가까운 처리량을 사용하여 UDP를 통해 안정적인 통신에 도달하기가 어렵습니다.

6.1. 패킷 드롭 감지

커널이 패킷을 삭제할 수 있는 네트워크 스택에는 여러 수준이 있습니다. Red Hat Enterprise Linux는 이러한 수준의 통계를 표시하는 다양한 유틸리티를 제공합니다. 이를 사용하여 잠재적인 문제를 파악할 수 있습니다.

삭제된 패킷의 매우 작은 속도를 무시할 수 있습니다. 그러나 상당한 속도가 발생하는 경우 튜닝 조치를 고려하십시오.

참고

네트워킹 스택에서 들어오는 트래픽을 처리할 수 없는 경우 커널은 네트워크 패킷을 삭제합니다.

프로세스

  • 너무 작은 소켓 버퍼 또는 애플리케이션 처리 속도 저하로 인해 UDP 프로토콜별 패킷 드롭을 식별합니다.

    # nstat -az UdpSndbufErrors UdpRcvbufErrors
    #kernel
    UdpSndbufErrors           4    0.0
    UdpRcvbufErrors    45716659    0.0
    Copy to Clipboard Toggle word wrap

    출력의 두 번째 열에는 카운터가 나열됩니다.

6.2. iperf3을 사용하여 UDP 처리량 테스트

iperf3 유틸리티는 두 호스트 간에 네트워크 처리량 테스트를 수행하는 서버와 클라이언트 모드를 제공합니다.

참고

애플리케이션의 처리량은 애플리케이션에서 사용하는 버퍼 크기와 같은 여러 요인에 따라 달라집니다. 따라서 iperf3 과 같은 테스트 유틸리티로 측정된 결과는 프로덕션 워크로드의 서버의 애플리케이션과 크게 다를 수 있습니다.

사전 요구 사항

  • iperf3 패키지는 클라이언트와 서버 둘 다에 설치됩니다.
  • 두 호스트의 다른 서비스는 테스트 결과에 상당한 영향을 미치는 네트워크 트래픽을 유발하지 않습니다.
  • 선택 사항: 서버와 클라이언트 모두에서 최대 UDP 소켓 크기를 늘렸습니다. 자세한 내용은 시스템 전체 UDP 소켓 버퍼 중단을 참조하십시오.

프로세스

  1. 선택 사항: 서버와 클라이언트 모두에서 NIC(네트워크 인터페이스 컨트롤러)의 최대 네트워크 속도를 표시합니다.

    # ethtool enp1s0 | grep "Speed"
       Speed: 10000Mb/s
    Copy to Clipboard Toggle word wrap
  2. 서버에서 다음을 수행합니다.

    1. 최대 UDP 소켓 읽기 버퍼 크기를 표시하고 값을 확인합니다.

      # sysctl net.core.rmem_max
      net.core.rmem_max = 16777216
      Copy to Clipboard Toggle word wrap

      표시된 값은 바이트 단위입니다.

    2. firewalld 서비스에서 기본 iperf3 포트 5201을 일시적으로 엽니다.

      # firewall-cmd --add-port=5201/tcp --add-port=5201/udp
      Copy to Clipboard Toggle word wrap

      iperf3 은 서버에서 TCP 소켓만 엽니다. 클라이언트에서 UDP를 사용하려는 경우 먼저 이 TCP 포트에 연결한 다음 서버는 UDP 트래픽 처리량 테스트를 수행하기 위해 동일한 포트 번호에 UDP 소켓을 엽니다. 따라서 로컬 방화벽에서 TCP 및 UDP 프로토콜 모두에 대해 포트 5201을 열어야 합니다.

    3. 서버 모드에서 iperf3 을 시작합니다.

      # iperf3 --server
      Copy to Clipboard Toggle word wrap

      이제 서비스는 들어오는 클라이언트 연결을 기다립니다.

  3. 클라이언트에서 다음을 수행합니다.

    1. 클라이언트가 서버 연결에 사용할 인터페이스의 최대 전송 단위(MTU)를 표시하고 값을 기록합니다.

      # ip link show enp1s0
      2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
      ...
      Copy to Clipboard Toggle word wrap
    2. 최대 UDP 소켓 쓰기 버퍼 크기를 표시하고 값을 확인합니다.

      # sysctl net.core.wmem_max
      net.core.wmem_max = 16777216
      Copy to Clipboard Toggle word wrap

      표시된 값은 바이트 단위입니다.

    3. 처리량 측정을 시작합니다.

      # iperf3 --udp --time 60 --window 16777216 --length 1472 --bitrate 2G --client 192.0.2.1
      Copy to Clipboard Toggle word wrap
      • --UDP: 테스트에 UDP 프로토콜을 사용합니다.
      • --time <seconds > : 클라이언트가 전송을 중지한 시간을 초 단위로 정의합니다.
      • --window & lt;size > : UDP 소켓 버퍼 크기를 설정합니다. 이상적으로는 클라이언트와 서버 모두에서 크기가 동일합니다. 서로 다른 경우 이 매개변수를 클라이언트의 net.core.wmem_max 또는 서버의 net.core.rmem_max 값으로 설정합니다.
      • --length <size > : 읽고 쓸 버퍼의 길이를 설정합니다. 이 옵션을 조각화되지 않은 가장 큰 페이로드로 설정합니다. MTU - IP 헤더(IPv4의 경우 20바이트, IPv6의 경우 40바이트) - 8바이트 UDP 헤더와 같이 이상적인 값을 계산합니다.
      • --bit rate &lt;rate> : 비트 속도를 초당 지정된 값으로 제한합니다. 2Gbps의 경우 2G 와 같은 단위를 지정할 수 있습니다.

        이 매개변수를 작업할 것으로 예상되는 값으로 설정하고 이후 측정에서 늘립니다. 클라이언트가 전송 경로의 장치보다 빠른 속도로 패킷을 전송하거나 서버에서 처리할 수 있는 경우 패킷을 삭제할 수 있습니다.

      • --client <server >: 클라이언트 모드를 활성화하고 iperf3 서버를 실행하는 서버의 IP 주소 또는 이름을 설정합니다.
  4. iperf3 이 테스트를 완료할 때까지 기다립니다. 서버와 클라이언트 모두 통계를 1초마다 표시하고 마지막에 요약을 표시합니다. 예를 들어 다음은 클라이언트에 표시되는 요약입니다.

    [ ID] Interval       Transfer      Bitrate         Jitter    Lost/Total Datagrams
    [ 5] 0.00-60.00 sec  14.0 GBytes   2.00 Gbits/sec  0.000 ms  0/10190216 (0%) sender
    [ 5] 0.00-60.04 sec  14.0 GBytes   2.00 Gbits/sec  0.002 ms  0/10190216 (0%) receiver
    Copy to Clipboard Toggle word wrap

    이 예에서는 평균 비트 비율이 2Gbps이고 패킷이 손실되지 않았습니다.

  5. 서버에서 다음을 수행합니다.

    1. Ctrl+C 눌러 iperf3 서버를 중지합니다.
    2. firewalld 에서 포트 5201을 종료합니다.

      # firewall-cmd --remove-port=5201/tcp --remove-port=5201/udp
      Copy to Clipboard Toggle word wrap

6.3. UDP 트래픽 처리량에 MTU 크기 영향

애플리케이션에서 큰 UDP 메시지 크기를 사용하는 경우 점보 프레임을 사용하면 처리량이 향상될 수 있습니다. IEEE 802.3 표준에 따르면 VLAN(Virtual Local Area Network) 태그가 없는 기본 이더넷 프레임의 최대 크기는 1518바이트입니다. 이러한 프레임 각각은 18바이트 헤더를 포함하며 페이로드를 위해 1500바이트를 남겨 둡니다. 그 결과, 1500바이트의 데이터마다 서버가 네트워크를 통해 전송되는 경우 18바이트(1.2%)는 오버헤드입니다.

점보 프레임은 1500바이트의 표준 이더넷 페이로드 크기보다 더 큰 최대 전송 단위(MTU)가 있는 비표준 프레임입니다. 예를 들어 허용되는 최대 MTU가 9000바이트 페이로드인 점보 프레임을 구성하는 경우 각 프레임의 오버헤드가 0.2%로 줄어듭니다.

중요

전송 경로 및 관련 브로드캐스트 도메인의 모든 네트워크 장치는 점보 프레임을 지원하고 동일한 MTU를 사용해야 합니다. 전송 경로의 MTU 설정에서 일관되지 않은 MTU 설정으로 인해 패킷 조각화 및 재 조립으로 인해 네트워크 처리량이 줄어듭니다.

서로 다른 연결 유형에는 특정 MTU 제한이 있습니다.

  • 이더넷: MTU는 9000바이트로 제한됩니다.
  • 데이터그램 모드에서 IP(IPP over InfiniBand): MTU는 InfiniBand MTU보다 4바이트로 제한됩니다.
  • 메모리 내 네트워킹은 일반적으로 더 큰 MTU를 지원합니다. 자세한 내용은 해당 문서를 참조하십시오.

6.4. UDP 트래픽 처리량에 CPU 속도의 영향

대규모 전송에서 UDP 프로토콜은 주로 UDP에서 패킷 집계가 누락되어 TCP보다 효율적이지 않습니다. 기본적으로 GRO(Generic Receive Offload) 및 UDP Segmentation Offload(USO) 기능이 활성화되어 있지 않습니다. 결과적으로 CPU 빈도는 고속 링크에서 대량 전송을 위해 UDP 처리량을 제한할 수 있습니다.

예를 들어, 최대 전송 단위(MTU) 및 대규모 소켓 버퍼가 있는 tuned 호스트에서 3 Cryostat CPU는 UDP 트래픽을 전체 속도로 보내거나 수신하는 10GBit NIC의 트래픽을 처리할 수 있습니다. 그러나 UDP 트래픽을 전송할 때 3 Cryostat 미만의 CPU 속도마다 약 1-2Gbps 속도 손실을 기대할 수 있습니다. 또한 CPU 속도가 10Gbps를 밀접하게 달성할 수 있는 경우 동일한 CPU는 40GBit NIC의 UDP 트래픽을 약 20~25Gbps로 제한합니다.

6.5. 시스템 전체 UDP 소켓 버퍼 증가

소켓 버퍼는 커널이 수신했거나 보내야 하는 데이터를 일시적으로 저장합니다.

  • 읽기 소켓 버퍼는 커널이 수신했지만 애플리케이션을 아직 읽지 않은 패킷을 보유합니다.
  • 쓰기 소켓 버퍼는 애플리케이션이 버퍼에 기록했지만 커널이 아직 IP 스택 및 네트워크 드라이버에 전달되지 않은 패킷을 보유합니다.

UDP 패킷이 너무 커서 버퍼 크기 또는 패킷이 너무 빠른 속도로 전송 또는 수신되는 경우 커널은 데이터가 버퍼에서 제거될 때까지 새로운 들어오는 UDP 패킷을 삭제합니다. 이 경우 소켓 버퍼를 늘리면 패킷 손실을 방지할 수 있습니다.

중요

너무 큰 버퍼 크기를 설정하면 메모리가 낭비됩니다. 각 소켓은 애플리케이션 요청 크기로 설정할 수 있으며 커널은 이 값을 두 배로 늘립니다. 예를 들어, 애플리케이션에서 256KiB 소켓 버퍼 크기를 요청하고 1백만 개의 소켓을 여는 경우 잠재적인 소켓 버퍼 공간에만 512GB RAM(512 KiB x 1 million)이 필요합니다.

사전 요구 사항

  • 삭제된 UDP 패킷의 상당한 비율이 발생했습니다.

프로세스

  1. 요구 사항에 따라 /etc/sysctl.d/10-udp-socket-buffers.conf 파일을 생성하고 최대 읽기 또는 쓰기 버퍼 크기를 설정하거나 둘 다 설정합니다.

    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    Copy to Clipboard Toggle word wrap

    값을 바이트 단위로 지정합니다. 이 예제의 값은 최대 버퍼 크기를 16MiB로 설정합니다. 두 매개변수의 기본값은 212992 바이트 (208 KiB)입니다.

  2. /etc/sysctl.d/10-udp-socket-buffers.conf 파일에서 설정을 로드합니다.

    # sysctl -p /etc/sysctl.d/10-udp-socket-buffers.conf
    Copy to Clipboard Toggle word wrap
  3. 더 큰 소켓 버퍼 크기를 사용하도록 애플리케이션을 구성합니다.

    net.core.rmem_maxnet.core.wmem_max 매개 변수는 애플리케이션의 setsockopt() 함수에서 요청할 수 있는 최대 버퍼 크기를 정의합니다. setsockopt() 함수를 사용하지 않도록 애플리케이션을 구성하는 경우 커널은 rmem_defaultwmem_default 매개변수의 값을 사용합니다.

    자세한 내용은 애플리케이션 프로그래밍 언어 설명서를 참조하십시오. 애플리케이션 개발자가 아닌 경우 개발자에게 문의하십시오.

  4. 애플리케이션을 다시 시작하여 새 UDP 버퍼 크기를 사용합니다.

검증

  • 패킷이 삭제될 때 사용한 것과 동일한 방법을 사용하여 패킷 드롭 통계를 모니터링합니다.

    패킷이 계속 감소하지만 더 낮은 속도로 발생하는 경우 버퍼 크기를 더 늘립니다.

7장. 애플리케이션 읽기 소켓 버퍼 병목 현상 확인

TCP 애플리케이션에서 읽기 소켓 버퍼를 자주 지우지 않으면 성능이 저하되고 패킷이 손실될 수 있습니다. Red Hat Enterprise Linux는 이러한 문제를 식별하는 다양한 유틸리티를 제공합니다.

7.1. 수신 버퍼 축소 및 정리 확인

수신 대기열의 데이터가 수신 버퍼 크기를 초과하면 TCP 스택은 소켓 버퍼에서 불필요한 메타데이터를 제거하여 일부 공간을 확보하려고 합니다. 이 단계를 접착이라고 합니다.

축소가 추가 트래픽을 위한 충분한 공간을 확보하지 못하면 커널에 도달하는 새 데이터가 정리됩니다. 즉, 커널이 메모리에서 데이터를 제거하고 패킷이 손실됩니다.

축소 및 정리 작업을 방지하려면 TCP 버퍼 축소 및 정리가 서버에서 수행되는지 여부를 모니터링하고 이 경우 TCP 버퍼를 조정합니다.

프로세스

  1. nstat 유틸리티를 사용하여 TcpExtTCPRcvCollapsedTcpExtRcvPruned 카운터를 쿼리합니다.

    # nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned
    #kernel
    TcpExtRcvPruned            0         0.0
    TcpExtTCPRcvCollapsed      612859    0.0
    Copy to Clipboard Toggle word wrap
  2. 잠시 기다렸다가 nstat 명령을 다시 실행합니다.

    # nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned
    #kernel
    TcpExtRcvPruned            0         0.0
    TcpExtTCPRcvCollapsed      620358    0.0
    Copy to Clipboard Toggle word wrap
  3. 첫 번째 실행에 비해 카운터 값이 증가한 경우 튜닝이 필요합니다.

    • 애플리케이션에서 setsockopt(SO_RCVBUF) 호출을 사용하는 경우 이를 제거하는 것이 좋습니다. 이 호출을 사용하면 애플리케이션은 호출에 지정된 수신 버퍼 크기만 사용하여 크기를 자동으로 조정하는 소켓의 기능을 끕니다.
    • 애플리케이션에서 setsockopt(SO_RCVBUF) 호출을 사용하지 않는 경우 TCP 읽기 소켓 버퍼의 기본값 및 최대 값을 조정합니다.
  4. 수신 백로그 대기열(Recv-Q)을 표시합니다.

    # ss -nti
    State   Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
    ESTAB   0        0        192.0.2.1:443        192.0.2.125:41574
          :7,7 ... lastrcv:543 ...
    ESTAB   78       0        192.0.2.1:443        192.0.2.56:42612
          :7,7 ... lastrcv:658 ...
    ESTAB   88       0        192.0.2.1:443        192.0.2.97:40313
          :7,7 ... lastrcv:5764 ...
    ...
    Copy to Clipboard Toggle word wrap
  5. 각 실행 사이에 몇 초 동안 대기 시간을 사용하여 ss -nt 명령을 여러 번 실행합니다.

    출력에 Recv-Q 열에 높은 값의 한 사례만 나열하는 경우 애플리케이션은 두 개의 수신 작업 사이에 있었습니다. 그러나 lastrcv -Q의 값이 지속적으로 증가하는 동안 Recv-Q 의 값이 일정하게 유지되거나 Recv-Q 가 지속적으로 증가하는 경우 다음 문제 중 하나가 원인일 수 있습니다.

    • 애플리케이션에서 소켓 버퍼를 충분히 확인하지 않습니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 애플리케이션 벤더에 문의하십시오.
    • 애플리케이션에 CPU 시간이 충분하지 않습니다. 이 문제를 추가로 디버깅하려면 다음을 수행합니다.

      1. 애플리케이션이 실행하는 CPU 코어를 표시합니다.

        # ps -eo pid,tid,psr,pcpu,stat,wchan:20,comm
            PID     TID PSR %CPU STAT WCHAN                COMMAND
        ...
          44594   44594   5  0.0 Ss   do_select            httpd
          44595   44595   3  0.0 S    skb_wait_for_more_pa httpd
          44596   44596   5  0.0 Sl   pipe_read            httpd
          44597   44597   5  0.0 Sl   pipe_read            httpd
          44602   44602   5  0.0 Sl   pipe_read            httpd
        ...
        Copy to Clipboard Toggle word wrap

        PSR 열에는 프로세스가 현재 할당한 CPU 코어가 표시됩니다.

      2. 동일한 코어에서 실행되는 다른 프로세스를 식별하고 다른 코어에 할당하는 것이 좋습니다.

8장. 많은 수의 들어오는 요청을 사용하여 애플리케이션 튜닝

웹 서버와 같이 들어오는 많은 요청을 처리하는 애플리케이션을 실행하는 경우 Red Hat Enterprise Linux를 조정하여 성능을 최적화해야 할 수 있습니다.

8.1. 많은 수의 TCP 연결 시도를 처리하기 위해 TCP 수신 백로그 조정

애플리케이션이 LISTEN 상태에서 TCP 소켓을 열면 커널은 이 소켓에서 처리할 수 있는 허용되는 클라이언트 연결 수를 제한합니다. 클라이언트가 처리할 수 있는 애플리케이션보다 더 많은 연결을 설정하려고 하면 새 연결이 손실되거나 커널에서 SYN 쿠키를 클라이언트에 보냅니다.

정상적인 워크로드가 있고 합법적 클라이언트의 연결이 너무 많은 경우 커널이 SYN 쿠키를 전송하고 이를 방지하기 위해 RHEL(Red Hat Enterprise Linux)을 조정합니다.

사전 요구 사항

  • RHEL은 Systemd 저널의 포트 < ip_address > : <port_number> 오류 메시지에서 SYN 플러딩이 발생할 수 있습니다.
  • 연결 시도가 많은 수는 유효한 소스에서 발생하며 공격으로 인한 것이 아닙니다.

프로세스

  1. 튜닝이 필요한지 확인하려면 영향을 받는 포트의 통계를 표시합니다.

    # ss -ntl '( sport = :443 )'
    State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port  Process
    LISTEN   650      500      192.0.2.1:443        0.0.0.0:*
    Copy to Clipboard Toggle word wrap

    백로그(Recv-Q)의 현재 연결 수가 소켓 백로그(전송-Q)보다 크면 수신 백로그가 여전히 충분히 크지 않고 튜닝이 필요합니다.

  2. 선택 사항: 현재 TCP 수신 백로그 제한을 표시합니다.

    # sysctl net.core.somaxconn
    net.core.somaxconn = 4096
    Copy to Clipboard Toggle word wrap
  3. /etc/sysctl.d/10-socket-backlog-limit.conf 파일을 생성하고 더 큰 수신 백로그 제한을 설정합니다.

    net.core.somaxconn = 8192
    Copy to Clipboard Toggle word wrap

    애플리케이션은 net.core.somaxconn 커널 매개변수에 지정된 것보다 더 큰 수신 백로그를 요청할 수 있지만 커널은 이 매개변수에 설정한 수로 애플리케이션을 제한합니다.

  4. /etc/sysctl.d/10-socket-backlog-limit.conf 파일에서 설정을 로드합니다.

    # sysctl -p /etc/sysctl.d/10-socket-backlog-limit.conf
    Copy to Clipboard Toggle word wrap
  5. 새 수신 백로그 제한을 사용하도록 애플리케이션을 재구성합니다.

    • 애플리케이션에서 제한에 대한 구성 옵션을 제공하는 경우 업데이트합니다. 예를 들어 Apache HTTP Server는 이 서비스에 대한 수신 백로그 제한을 설정하는 ListenBacklog 구성 옵션을 제공합니다.
    • 제한을 구성할 수 없는 경우 애플리케이션을 다시 컴파일합니다.
    중요

    항상 net.core.somaxconn 커널 설정과 애플리케이션의 설정을 모두 업데이트해야 합니다.

  6. 애플리케이션을 다시 시작합니다.

검증

  1. 포트 < port_number> 오류 메시지에서 SYN 플러딩 가능한 추가 발생을 위해 Systemd 저널을 모니터링합니다.
  2. 백로그에서 현재 연결 수를 모니터링하고 소켓 백로그와 비교합니다.

    # ss -ntl '( sport = :443 )'
    State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port  Process
    LISTEN   0        500      192.0.2.1:443        0.0.0.0:*
    Copy to Clipboard Toggle word wrap

    백로그(Recv-Q)의 현재 연결 수가 소켓 백로그(전송-Q)보다 크면 수신 백로그가 충분히 크지 않고 추가 튜닝이 필요합니다.

9장. 수신 대기열 잠금 경합 방지

큐 잠금 경합으로 인해 패킷이 삭제되고 CPU 사용량이 증가할 수 있으므로 대기 시간이 길어집니다. 애플리케이션을 튜닝하고 전송 패킷 셰이핑을 사용하여 수신(RX)에서 큐 잠금 경합을 방지하고 TX(TX) 큐를 전송할 수 있습니다.

9.1. RX 대기열 잠금 경합 방지: SO_REUSEPORT 및 SO_REUSEPORT_BPF 소켓 옵션

멀티 코어 시스템에서는 애플리케이션이 SO_REUSEPORT 또는 SO_REUSEPORT_BPF 소켓 옵션을 사용하여 포트를 여는 경우 멀티 스레드 네트워크 서버 애플리케이션의 성능을 향상시킬 수 있습니다. 애플리케이션에서 이러한 소켓 옵션 중 하나를 사용하지 않는 경우 모든 스레드는 들어오는 트래픽을 수신하기 위해 단일 소켓을 공유해야 합니다. 단일 소켓을 사용하면 다음과 같은 원인이 됩니다.

  • 수신 버퍼에서 상당한 경합으로 인해 패킷이 삭제되고 CPU 사용량이 증가할 수 있습니다.
  • CPU 사용량이 크게 증가
  • 패킷이 삭제될 수 있음
잠금 경합

SO_REUSEPORT 또는 SO_REUSEPORT_BPF 소켓 옵션을 사용하면 한 호스트의 여러 소켓이 동일한 포트에 바인딩할 수 있습니다.

따라서 reuseport

자세한 내용은 시스템의 socket(7) 도움말 페이지 및 /usr/src/debug/kernel- <version> /linux- <version> /tools/testing/selftests/net/reuseport_bpf_cpu.c 파일을 참조하십시오.

Red Hat Enterprise Linux는 커널 소스에서 SO_REUSEPORT 소켓 옵션을 사용하는 방법에 대한 코드 예제를 제공합니다. 코드 예제에 액세스하려면 다음을 수행합니다.

  1. rhel-9-for-x86_64-baseos-debug-rpms 리포지토리를 활성화합니다.

    # subscription-manager repos --enable rhel-10-for-x86_64-baseos-debug-rpms
    Copy to Clipboard Toggle word wrap
  2. kernel-debuginfo-common-x86_64 패키지를 설치합니다.

    # dnf install kernel-debuginfo-common-x86_64
    Copy to Clipboard Toggle word wrap
  3. 코드 예제는 /usr/src/debug/kernel- <version> /linux- <version> /tools/testing/selftests/net/reuseport_bpf_cpu.c 파일에서 사용할 수 있습니다.

9.2. TX 큐 잠금 경합 방지: 패킷 이동

여러 큐를 지원하는 NIC(네트워크 인터페이스 컨트롤러)가 있는 호스트에서 패킷 셰이핑(XPS)은 발신 네트워크 패킷 처리를 여러 큐에 배포합니다. 이를 통해 여러 CPU에서 발신 네트워크 트래픽을 처리하고 전송 대기열 잠금 경합을 방지하기 위해 패킷이 삭제됩니다.

ixgbe,i40emlx5 와 같은 특정 드라이버는 XPS를 자동으로 구성합니다. 드라이버가 이 기능을 지원하는지 확인하려면 NIC 드라이버 설명서를 참조하십시오. NIC 드라이버 설명서를 참조하여 드라이버가 이 기능을 지원하는지 확인합니다. 드라이버가 XPS 자동 튜닝을 지원하지 않는 경우 전송 큐에 CPU 코어를 수동으로 할당할 수 있습니다.

참고

Red Hat Enterprise Linux는 CPU 코어에 전송 대기열을 영구적으로 할당할 수 있는 옵션을 제공하지 않습니다. 인터페이스가 활성화되면 실행되는 NetworkManager 디스패치 스크립트의 명령을 사용합니다. 자세한 내용은 인터페이스 시작 시 명령을 적용하기 위해 NetworkManager 디스패처 스크립트를 작성하는 방법을 참조하십시오.

Linux 네트워킹 스택의 스케일링에 대한 자세한 내용은 kernel-doc 패키지에서 제공하는 /usr/share/doc/kernel-doc- <version> /Documentation/networking/scaling.rst 파일을 참조하십시오.

사전 요구 사항

  • NIC는 여러 큐를 지원합니다.
  • numactl 패키지가 설치되어 있습니다.

프로세스

  1. 사용 가능한 대기열 수를 표시합니다.

    # ethtool -l enp1s0
    Channel parameters for enp1s0:
    Pre-set maximums:
    RX:		0
    TX:		0
    Other:		0
    Combined:	4
    Current hardware settings:
    RX:		0
    TX:		0
    Other:		0
    Combined:	1
    Copy to Clipboard Toggle word wrap

    사전 설정 최대값 섹션에서는 총 대기열 수와 현재 하드웨어 설정을 수신, 전송, 기타 또는 결합된 큐에 현재 할당한 대기열 수를 보여줍니다.

  2. 선택 사항: 특정 채널에 대기열이 필요한 경우 그에 따라 큐를 할당합니다. 예를 들어, 4개의 대기열을 Combined 채널에 할당하려면 다음을 입력합니다.

    # ethtool -L enp1s0 combined 4
    Copy to Clipboard Toggle word wrap
  3. NIC가 할당되는 NUMA(Non-Uniform Memory Access) 노드를 표시합니다.

    # cat /sys/class/net/enp1s0/device/numa_node
    0
    Copy to Clipboard Toggle word wrap

    파일이 없거나 명령이 -1 을 반환하면 호스트는 NUMA 시스템이 아닙니다.

  4. 호스트가 NUMA 시스템인 경우 어떤 NUMA 노드에 할당되는 CPU를 표시합니다.

    # lscpu | grep NUMA
    NUMA node(s):       2
    NUMA node0 CPU(s):  0-3
    NUMA node1 CPU(s):  4-7
    Copy to Clipboard Toggle word wrap
  5. 위의 예에서 NIC에는 4개의 큐가 있으며 NIC는 NUMA 노드 0에 할당됩니다. 이 노드는 CPU 코어 0-3을 사용합니다. 결과적으로 각 전송 대기열을 0-3의 CPU 코어 중 하나에 매핑합니다.

    # echo 1 > /sys/class/net/enp1s0/queues/tx-0/xps_cpus
    # echo 2 > /sys/class/net/enp1s0/queues/tx-1/xps_cpus
    # echo 4 > /sys/class/net/enp1s0/queues/tx-2/xps_cpus
    # echo 8 > /sys/class/net/enp1s0/queues/tx-3/xps_cpus
    Copy to Clipboard Toggle word wrap

    CPU 코어 및 전송(TX) 대기열의 수가 동일한 경우 1~1 매핑을 사용하여 TX 대기열의 모든 종류의 경합을 방지합니다. 그렇지 않으면 동일한 TX 큐에 여러 CPU를 매핑하는 경우 다른 CPU에서 작업을 전송하면 TX 대기열 잠금 경합이 발생하고 전송 처리량에 부정적인 영향을 미칩니다.

    CPU의 코어 번호를 포함하는 비트맵을 큐에 전달해야 합니다. 다음 명령을 사용하여 비트맵을 계산합니다.

    # printf %x $((1 << <core_number> ))
    Copy to Clipboard Toggle word wrap

검증

  1. 트래픽을 전송하는 서비스의 프로세스 ID(PID)를 식별합니다.

    # pidof <process_name>
    12345 98765
    Copy to Clipboard Toggle word wrap
  2. XPS를 사용하는 코어에 PID를 고정합니다.

    # numactl -C 0-3 12345 98765
    Copy to Clipboard Toggle word wrap
  3. 프로세스에서 트래픽을 보내는 동안 requeues 카운터를 모니터링합니다.

    # tc -s qdisc
    qdisc fq_codel 0: dev enp10s0u1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
     Sent 125728849 bytes 1067587 pkt (dropped 0, overlimits 0 requeues 30)
     backlog 0b 0p requeues 30
     ...
    Copy to Clipboard Toggle word wrap

    큐 카운터가 더 이상 상당한 속도로 증가하지 않으면 TX 큐 잠금 경합이 더 이상 발생하지 않습니다.

9.3. UDP 트래픽이 높은 서버에서 Generic Receive Offload 기능 비활성화

고속 UDP 대량 전송을 사용하는 애플리케이션은 UDP 소켓에서 UDP GRO(Generic Receive Offload)를 활성화하고 사용해야 합니다. 그러나 다음 조건이 적용되는 경우 GRO를 비활성화하여 처리량을 늘릴 수 있습니다.

  • 애플리케이션은 GRO를 지원하지 않으며 기능을 추가할 수 없습니다.
  • TCP 처리량은 관련이 없습니다.

    주의

    GRO를 비활성화하면 TCP 트래픽의 수신 처리량이 크게 줄어듭니다. 따라서 TCP 성능이 관련된 호스트에서 GRO를 비활성화하지 마십시오.

사전 요구 사항

  • 호스트는 주로 UDP 트래픽을 처리합니다.
  • 애플리케이션에서 GRO를 사용하지 않습니다.
  • 호스트는 VXLAN과 같은 UDP 터널 프로토콜을 사용하지 않습니다.
  • 호스트에서 VM(가상 머신) 또는 컨테이너를 실행하지 않습니다.

프로세스

  1. 선택 사항: NetworkManager 연결 프로필을 표시합니다.

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
    Copy to Clipboard Toggle word wrap
  2. 연결 프로필에서 GRO 지원을 비활성화합니다.

    # nmcli connection modify example ethtool.feature-gro off
    Copy to Clipboard Toggle word wrap
  3. 연결 프로필을 다시 활성화합니다.

    # nmcli connection up example
    Copy to Clipboard Toggle word wrap

검증

  1. GRO가 비활성화되어 있는지 확인합니다.

    # ethtool -k enp1s0 | grep generic-receive-offload
    generic-receive-offload: off
    Copy to Clipboard Toggle word wrap
  2. 서버의 처리량을 모니터링합니다. 설정이 호스트의 다른 애플리케이션에 부정적인 영향을 미치는 경우 NetworkManager 프로필에서 GRO를 다시 활성화합니다.

10장. 장치 드라이버 및 NIC 튜닝

RHEL에서 커널 모듈은 NIC(네트워크 인터페이스 컨트롤러)에 대한 드라이버를 제공합니다. 이러한 모듈은 매개변수를 지원하여 장치 드라이버와 NIC를 튜닝하고 최적화합니다. 예를 들어, 드라이버가 수신 인터럽트 생성 지연을 지원하는 경우 해당 매개변수의 값을 줄여 수신 설명자가 실행되지 않도록 할 수 있습니다.

참고

모든 모듈이 사용자 지정 매개 변수를 지원하는 것은 아니며 기능은 하드웨어 및 드라이버 및 펌웨어 버전에 따라 다릅니다.

10.1. 사용자 정의 NIC 드라이버 매개변수 구성

많은 커널 모듈은 설정 매개변수를 지원하여 드라이버와 NIC(네트워크 인터페이스 컨트롤러)를 조정할 수 있습니다. 하드웨어 및 드라이버에 따라 설정을 사용자 지정할 수 있습니다.

중요

커널 모듈에서 매개변수를 설정하면 RHEL은 이러한 설정을 이 드라이버를 사용하는 모든 장치에 적용합니다.

사전 요구 사항

  • NIC가 호스트에 설치되어 있습니다.
  • NIC에 대한 드라이버를 제공하는 커널 모듈은 필요한 튜닝 기능을 지원합니다.
  • 로컬로 로그인하거나 매개 변수를 변경하려는 드라이버를 사용하는 네트워크와 다른 네트워크 인터페이스를 사용하여 로그인합니다.

프로세스

  1. 드라이버를 확인합니다.

    # ethtool -i enp0s31f6
    driver: e1000e
    version: ...
    firmware-version: ...
    ...
    Copy to Clipboard Toggle word wrap

    특정 기능에는 특정 드라이버 및 펌웨어 버전이 필요할 수 있습니다.

  2. 커널 모듈의 사용 가능한 매개변수를 표시합니다.

    # modinfo -p e1000e
    ...
    SmartPowerDownEnable:Enable PHY smart power down (array of int)
    parm:RxIntDelay:Receive Interrupt Delay (array of int)
    Copy to Clipboard Toggle word wrap

    매개변수에 대한 자세한 내용은 커널 모듈 설명서를 참조하십시오. RHEL의 모듈의 경우 kernel-doc 패키지에서 제공하는 /usr/share/doc/kernel-doc- <version> /Documentation/networking/device_drivers/ 디렉터리에 있는 설명서를 참조하십시오.

  3. /etc/modprobe.d/nic-parameters.conf 파일을 생성하고 모듈에 대한 매개변수를 지정합니다.

    options <module_name> <parameter1>=<value> <parameter2>=<value>
    Copy to Clipboard Toggle word wrap

    예를 들어 포트 전원 저장 메커니즘을 활성화하고 수신 인터럽트 생성을 4 단위로 설정하려면 다음을 입력합니다.

    options e1000e SmartPowerDownEnable=1 RxIntDelay=4
    Copy to Clipboard Toggle word wrap
  4. 모듈을 언로드합니다.

    # modprobe -r e1000e
    Copy to Clipboard Toggle word wrap
    주의

    활성 네트워크 인터페이스에서 사용하는 모듈을 언로드하면 연결이 즉시 종료되고 서버에서 자신을 잠글 수 있습니다.

  5. 모듈을 로드합니다.

    # modprobe e1000e
    Copy to Clipboard Toggle word wrap
  6. 네트워크 연결을 다시 활성화합니다.

    # nmcli connection up <profile_name>
    Copy to Clipboard Toggle word wrap

검증

  1. 커널 메시지를 표시합니다.

    # dmesg
    ...
    [35309.225765] e1000e 0000:00:1f.6: Transmit Interrupt Delay set to 16
    [35309.225769] e1000e 0000:00:1f.6: PHY Smart Power Down Enabled
    ...
    Copy to Clipboard Toggle word wrap

    모든 모듈 로그 매개 변수 설정이 커널 링 버퍼에 적용되는 것은 아닙니다.

  2. 특정 커널 모듈은 /sys/module/ <driver> /parameters/ 디렉터리에서 각 모듈 매개변수에 대한 파일을 생성합니다. 이러한 각 파일에는 이 매개변수의 현재 값이 포함되어 있습니다. 이러한 파일을 표시하여 설정을 확인할 수 있습니다.

    # cat /sys/module/<driver_name>/parameters/<parameter_name>
    Copy to Clipboard Toggle word wrap

11장. 네트워크 어댑터 오프로드 설정 구성

CPU 로드를 줄이기 위해 특정 네트워크 어댑터는 오프로드 기능을 사용하여 네트워크 처리 부하를 NIC(네트워크 인터페이스 컨트롤러)로 이동합니다. 예를 들어 ESP(Security Payload) 오프로드를 캡슐화하는 경우 NIC는 ESP 작업을 수행하여 IPsec 연결을 가속화하고 CPU 로드를 줄입니다.

기본적으로 Red Hat Enterprise Linux의 대부분의 오프로드 기능이 활성화됩니다. 다음 경우에만 비활성화합니다.

  • 문제 해결을 위해 오프로드 기능을 일시적으로 비활성화합니다.
  • 특정 기능이 호스트에 부정적인 영향을 미치는 경우 오프로드 기능을 영구적으로 비활성화합니다.

네트워크 드라이버에서 성능 관련 오프로드 기능이 기본적으로 활성화되어 있지 않으면 수동으로 활성화할 수 있습니다.

11.1. 임시로 오프로드 기능 설정

오프로드 기능으로 문제가 발생하거나 호스트의 성능을 감소시킬 것으로 예상되는 경우 현재 상태에 따라 일시적으로 활성화하거나 비활성화하여 원인을 좁힐 수 있습니다.

오프로드 기능을 일시적으로 활성화하거나 비활성화하는 경우 다음 재부팅 시 이전 값으로 돌아갑니다.

사전 요구 사항

  • 네트워크 카드는 오프로드 기능을 지원합니다.

프로세스

  1. 인터페이스의 사용 가능한 오프로드 기능과 해당 현재 상태를 표시합니다.

    # ethtool -k enp1s0
    ...
    esp-hw-offload: on
    ntuple-filters: off
    rx-vlan-filter: off [fixed]
    ...
    Copy to Clipboard Toggle word wrap

    출력은 하드웨어 및 해당 드라이버의 기능에 따라 달라집니다. [고정] 으로 플래그되는 기능은 변경할 수 없습니다.

  2. 오프로드 기능을 일시적으로 비활성화합니다.

    # ethtool -K <interface> <feature> <on|off>
    Copy to Clipboard Toggle word wrap
    • 예를 들어 enp10s0u1 인터페이스에서ESP(Security Payload) 오프로드를 일시적으로 비활성화하려면 다음을 입력합니다.

      # ethtool -K enp10s0u1 esp-hw-offload off
      Copy to Clipboard Toggle word wrap
    • 예를 들어 enp10s0u1 인터페이스에서 가속식 Receive Flow Steering(aRFS) 필터링을 일시적으로 활성화하려면 다음을 입력합니다.

      # ethtool -K enp10s0u1 ntuple-filters on
      Copy to Clipboard Toggle word wrap

검증

  1. 오프로드 기능의 상태를 표시합니다.

    # ethtool -k enp1s0
    ...
    esp-hw-offload: off
    ntuple-filters: on
    ...
    Copy to Clipboard Toggle word wrap
  2. 오프로드 기능을 변경하기 전에 발생한 문제가 여전히 존재하는지 테스트합니다.

    • 특정 오프로드 기능을 변경한 후 문제가 더 이상 존재하지 않는 경우:

      1. Red Hat 지원에 문의하여 문제를 보고합니다.
      2. 수정 사항을 사용할 수 있을 때까지 오프로드 기능을 영구적으로 설정하는 것이 좋습니다.
    • 특정 오프로드 기능을 비활성화한 후에도 문제가 여전히 존재하는 경우:

      1. ethtool -K < interface > < feature > < on|off > 명령을 사용하여 설정을 이전 상태로 재설정합니다.
      2. 다른 오프로드 기능을 활성화하거나 비활성화하여 문제를 줄입니다.

11.2. 영구적으로 오프로드 기능 설정

호스트의 성능을 제한하는 특정 오프로드 기능을 확인한 경우 현재 상태에 따라 영구적으로 활성화하거나 비활성화할 수 있습니다.

오프로드 기능을 영구적으로 활성화하거나 비활성화하는 경우 NetworkManager는 재부팅 후에도 기능이 계속 이 상태를 유지합니다.

사전 요구 사항

  • 호스트의 성능을 제한하기 위해 특정 오프로드 기능을 확인했습니다.

프로세스

  1. 오프로드 기능의 상태를 변경할 네트워크 인터페이스를 사용하는 연결 프로필을 식별합니다.

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    Example  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1ss0
    ...
    Copy to Clipboard Toggle word wrap
  2. 오프로드 기능의 상태를 영구적으로 변경합니다.

    # nmcli connection modify <connection_name> <feature> <on|off>
    Copy to Clipboard Toggle word wrap
    • 예를 들어 예제 연결 프로필에서 AES(Security Payload) 오프로드를 영구적으로 비활성화하려면 다음을 입력합니다.

      # nmcli connection modify Example ethtool.feature-esp-hw-offload off
      Copy to Clipboard Toggle word wrap
    • 예를 들어 예제 연결 프로필에서 가속화된 수신 흐름 스테퍼링(aRFS) 필터링을 영구적으로 활성화하려면 다음을 입력합니다.

      # nmcli connection modify Example ethtool.feature-ntuple on
      Copy to Clipboard Toggle word wrap
  3. 연결 프로필을 다시 활성화합니다.

    # nmcli connection up Example
    Copy to Clipboard Toggle word wrap

검증

  • 오프로드 기능의 출력 상태를 표시합니다.

    # ethtool -k enp1s0
    ...
    esp-hw-offload: off
    ntuple-filters: on
    ...
    Copy to Clipboard Toggle word wrap

12장. 인터럽트 병합 설정 튜닝

인터럽트 병합은 네트워크 카드에서 생성된 인터럽트 수를 줄이기 위한 메커니즘입니다. 일반적으로 인터럽트 수가 감소하면 네트워크의 대기 시간과 전체 성능이 향상될 수 있습니다.

인터럽트 병합 설정을 튜닝하려면 다음을 제어하는 매개변수를 조정해야 합니다.

  • 단일 인터럽트에 결합된 패킷 수입니다.
  • 인터럽트를 생성하기 전 지연.
중요

최적의 병합 설정은 사용 중인 특정 네트워크 조건 및 하드웨어에 따라 다릅니다. 따라서 환경과 요구에 가장 적합한 설정을 찾기 위해 여러 번 시도할 수 있습니다.

12.1. 대기 시간 또는 처리량에 민감한 서비스를 위해 RHEL 최적화

병합 튜닝의 목표는 지정된 워크로드에 필요한 인터럽트 수를 최소화하는 것입니다. 처리량이 높은 상황에서 목표는 높은 데이터 속도를 유지하면서 가능한 한 적은 수의 인터럽트를 보유하는 것입니다. 대기 시간이 짧은 상황에서는 더 많은 인터럽트를 사용하여 트래픽을 신속하게 처리할 수 있습니다.

네트워크 카드의 설정을 조정하여 단일 인터럽트로 결합된 패킷 수를 늘리거나 줄일 수 있습니다. 결과적으로 트래픽의 처리량 또는 대기 시간을 개선할 수 있습니다.

프로세스

  1. 병목 현상이 발생하는 네트워크 인터페이스를 식별합니다.

    # ethtool -S enp1s0
    NIC statistics:
         rx_packets: 1234
         tx_packets: 5678
         rx_bytes: 12345678
         tx_bytes: 87654321
         rx_errors: 0
         tx_errors: 0
         rx_missed: 0
         tx_dropped: 0
         coalesced_pkts: 0
         coalesced_events: 0
         coalesced_aborts: 0
    Copy to Clipboard Toggle word wrap

    이름에서 드롭 삭제, 삭제 또는 오류가 포함된 패킷 카운터를 식별합니다. 이러한 특정 통계는 NIC(네트워크 인터페이스 카드) 패킷 버퍼에서 실제 패킷 손실을 측정하며, NIC 병합으로 인해 발생할 수 있습니다.

  2. 이전 단계에서 확인한 패킷 카운터 값을 모니터링합니다.

    네트워크에 대해 예상되는 값과 비교하여 특정 인터페이스에 병목 현상이 발생하는지 확인합니다. 네트워크 병목 현상의 몇 가지 일반적인 표시에는 다음이 포함되지만 이에 국한되지는 않습니다.

    • 네트워크 인터페이스에 많은 오류
    • 높은 패킷 손실
    • 네트워크 인터페이스의 사용량이 많이 있음

      참고

      다른 중요한 요인은 네트워크 병목 현상을 식별할 때 CPU 사용량, 메모리 사용량, 디스크 I/O 등의 중요한 요소입니다.

  3. 현재 인터럽트 병합 설정을 확인합니다.

    # ethtool -c enp1s0
    Coalesce parameters for enp1s0:
            Adaptive RX: off
            Adaptive TX: off
            RX usecs: 100
            RX frames: 8
            RX usecs irq: 100
            RX frames irq: 8
            TX usecs: 100
            TX frames: 8
            TX usecs irq: 100
            TX frames irq: 8
    Copy to Clipboard Toggle word wrap
    • usecs 값은 인터럽트를 생성하기 전에 수신자 또는 송신기가 대기하는 마이크로초의 수를 나타냅니다.
    • 프레임 값은 인터럽트를 생성하기 전에 수신자 또는 송신기가 대기하는 프레임 수를 나타냅니다.
    • irq 값은 네트워크 인터페이스에서 인터럽트를 이미 처리하고 있을 때 인터럽트 모드를 구성하는 데 사용됩니다.

      참고

      모든 네트워크 인터페이스 카드에서 예제 출력의 모든 값을 보고하고 변경하는 데 지원되지는 않습니다.

    • Adaptive RX/TX 값은 인터럽트 병합 설정을 동적으로 조정하는 Adaptive 인터럽트 병합 메커니즘을 나타냅니다. 패킷 상태에 따라 Adaptive RX/TX 가 활성화된 경우 NIC 드라이버에서 병합 값을 자동으로 계산합니다(각 NIC 드라이버마다 알고리즘이 다릅니다).
  4. 필요에 따라 병합 설정을 수정합니다. 예를 들면 다음과 같습니다.

    • ethtool.coalesce-adaptive-rx 는 비활성화되지만 RX 패킷에 대해 인터럽트 를 100 마이크로초로 생성하기 전에 지연을 설정하도록 ethtool.coalesce-rx 를 구성합니다.

      # nmcli connection modify enp1s0 ethtool.coalesce-rx-usecs 100
      Copy to Clipboard Toggle word wrap
    • ethtool.coalesce-rx-usecs 가 기본값으로 설정된 동안 ethtool.coalesce-adaptive-rx -rx를 활성화합니다.

      # nmcli connection modify enp1s0 ethtool.coalesce-adaptive-rx on
      Copy to Clipboard Toggle word wrap

      다음과 같이 Adaptive-RX 설정을 수정합니다.

      • 짧은 대기 시간(sub-50us)에 관련된 사용자는 Adaptive-RX 를 활성화해서는 안 됩니다.
      • 처리량에 관련된 사용자는 손상 없이 Adaptive-RX 를 활성화할 수 있습니다. Adaptive 인터럽트 병합 메커니즘을 사용하지 않으려면 100us와 같은 큰 값을 설정하거나 ethtool.coalesce-rx-usecs 로 250us를 설정할 수 있습니다.
      • 사용자가 문제가 발생할 때까지 요구 사항에 대해 잘 모르는 경우 이 설정을 수정해서는 안 됩니다.
  5. 연결을 다시 활성화합니다.

    # nmcli connection up enp1s0
    Copy to Clipboard Toggle word wrap

검증

  • 네트워크 성능을 모니터링하고 삭제된 패킷을 확인합니다.

    # ethtool -S enp1s0
    NIC statistics:
         rx_packets: 1234
         tx_packets: 5678
         rx_bytes: 12345678
         tx_bytes: 87654321
         rx_errors: 0
         tx_errors: 0
         rx_missed: 0
         tx_dropped: 0
         coalesced_pkts: 12
         coalesced_events: 34
         coalesced_aborts: 56
    ...
    Copy to Clipboard Toggle word wrap

    rx_errors,rx_dropped,tx_errors, tx_dropped 필드의 값은 0이어야 합니다(네트워크 트래픽 및 시스템 리소스에 따라 최대 수백 개까지). 이러한 필드의 높은 값은 네트워크 문제를 나타냅니다. 카운터는 다른 이름을 가질 수 있습니다. 이름에 "drop", "discard" 또는 "error"가 포함된 패킷 카운터를 밀접하게 모니터링합니다.

    rx_packets,tx_packets,rx_bytes, tx_bytes 의 값은 시간이 지남에 따라 증가해야 합니다. 값이 증가하지 않으면 네트워크에 문제가 있을 수 있습니다. NIC 드라이버에 따라 패킷 카운터의 이름이 다를 수 있습니다.

    중요

    ethtool 명령 출력은 사용 중인 NIC 및 드라이버에 따라 다를 수 있습니다.

    대기 시간이 매우 짧은 사용자는 모니터링 목적으로 애플리케이션 수준 메트릭 또는 커널 패킷 시간 샘플링 API를 사용할 수 있습니다.

13장. TCP Timestamps의 이점

TCP Timestamps는 TCP 헤더의 선택적 정보이며 TCP 프로토콜 확장입니다. 기본적으로 TCP Timestamp는 Red Hat Enterprise Linux에서 활성화되며 커널은 TCP 연결에서 RTT(Round trip Timestamp)를 보다 효과적으로 추정합니다. 따라서 TCP 창 및 버퍼 계산이 더 정확합니다.

또한 TCP Timestamps는 세그먼트의 나이와 순서를 결정하고 래핑된 시퀀스 번호로부터 보호하는 대체 방법을 제공합니다. TCP 패킷 헤더는 32비트 필드의 시퀀스 번호를 기록합니다. 10Gbps 연결에서 이 필드의 값은 1.7초 후에 래핑할 수 있습니다. TCP Timestamps가 없으면 수신자는 래핑된 시퀀스 번호가 있는 세그먼트가 새 세그먼트인지 또는 이전 중복인지를 확인할 수 없었습니다. 그러나 TCP Timestamps를 사용하면 수신자가 세그먼트를 수신하거나 삭제할 수 있는 올바른 선택을 할 수 있습니다. 따라서 빠른 네트워크 인터페이스가 있는 시스템에서 TCP Timestamp를 활성화하는 것이 중요합니다.

net.ipv4.tcp_timestamps 커널 매개변수에는 다음 값 중 하나가 있을 수 있습니다.

  • 0: TCP Timestamps는 비활성화되어 있습니다.
  • 1: TCP Timestamps가 활성화됩니다(기본값).
  • 2: TCP Timestamps는 활성화되지만 임의의 오프셋이 없습니다.

    중요

    각 연결에 대한 임의의 오프셋이 없으면 호스트의 가동 시간 및 지문을 대략 확인하고 이 정보를 공격에 사용할 수 있습니다.

기본적으로 TCP Timestamp는 Red Hat Enterprise Linux에서 활성화되며 현재 시간을 저장하는 대신 각 연결에 임의의 오프셋을 사용합니다.

# sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1
Copy to Clipboard Toggle word wrap

net.ipv4.tcp_timestamps 매개변수에 기본값(1)과 다른 값이 있는 경우 설정을 설정하는 것과 동일한 방식으로 설정을 되돌립니다.

14장. 이더넷 네트워크의 흐름 제어

이더넷 링크에서 네트워크 인터페이스와 스위치 포트 간의 지속적인 데이터 전송으로 인해 전체 버퍼 용량이 발생할 수 있습니다. 전체 버퍼 용량으로 인해 네트워크 정체가 발생합니다. 이 경우, 발신자가 수신기의 처리 용량보다 더 높은 속도로 데이터를 전송할 때, 패킷 손실은 링크의 다른 쪽 끝에 있는 네트워크 인터페이스의 데이터 처리 용량으로 인해 발생할 수 있습니다.

흐름 제어 메커니즘은 각 발신자와 수신자가 다른 전송 및 수신 용량을 갖는 이더넷 링크를 통한 데이터 전송을 관리합니다. 패킷 손실을 방지하기 위해 이더넷 흐름 제어 메커니즘은 스위치 포트에서 더 높은 전송 속도를 관리하기 위해 패킷 전송을 일시적으로 중단합니다. 스위치는 스위치 포트 이외의 일시 중지 프레임을 전달하지 않습니다.

수신(RX) 버퍼가 가득 차면 수신자는 일시 중지 프레임을 송신기에 보냅니다. 그런 다음 송신기는 이 일시 중지 기간 동안 들어오는 데이터를 버퍼링하는 동안 짧은 하위 시간 프레임에 대한 데이터 전송을 중지합니다. 이 기간은 수신자가 해당 인터페이스 버퍼를 비우고 버퍼 오버플로를 방지할 수 있는 충분한 시간을 제공합니다.

참고

이더넷 링크의 끝은 일시 중지 프레임을 다른 끝으로 보낼 수 있습니다. 네트워크 인터페이스의 수신 버퍼가 가득 차면 네트워크 인터페이스에서 일시 중지 프레임을 스위치 포트로 보냅니다. 마찬가지로, 스위치 포트의 수신 버퍼가 가득 차면 스위치 포트는 일시 중지 프레임을 네트워크 인터페이스로 보냅니다.

기본적으로 Red Hat Enterprise Linux의 대부분의 네트워크 드라이버에는 일시 중지 프레임 지원이 활성화되어 있습니다. 네트워크 인터페이스의 현재 설정을 표시하려면 다음을 입력합니다.

# ethtool --show-pause enp1s0
Pause parameters for enp1s0:
...
RX:     on
TX:     on
...
Copy to Clipboard Toggle word wrap

스위치 공급 업체에 문의하여 스위치가 일시 중지 프레임을 지원하는지 확인합니다.

15장. NetworkManager 연결 프로필에서 ethtool 설정 구성

NetworkManager는 특정 네트워크 드라이버 및 하드웨어 설정을 영구적으로 구성할 수 있습니다. ethtool 유틸리티를 사용하여 이러한 설정을 관리하는 것과 비교하여 재부팅 후 설정을 손실하지 않는 이점이 있습니다.

NetworkManager 연결 프로필에서 다음 ethtool 설정을 설정할 수 있습니다.

오프로드 기능
네트워크 인터페이스 컨트롤러는 TOE(TCP 오프로드 엔진)를 사용하여 특정 작업을 네트워크 컨트롤러에 오프로드할 수 있습니다. 이렇게 하면 네트워크 처리량이 향상됩니다.
병합 설정 중단
인터럽트 병합을 사용하면 시스템은 네트워크 패킷을 수집하고 여러 패킷에 대한 단일 인터럽트를 생성합니다. 이는 하나의 하드웨어 인터럽트를 사용하여 커널에 전송되는 데이터의 양을 증가시켜 인터럽트 부하를 줄이고 처리량을 극대화합니다.
링 버퍼
이러한 버퍼는 수신 및 발신 네트워크 패킷을 저장합니다. 링 버퍼 크기를 늘리면 패킷 드롭 속도를 줄일 수 있습니다.
채널 설정

네트워크 인터페이스는 하드웨어 설정 및 네트워크 드라이버와 함께 관련 채널 수를 관리합니다. 네트워크 인터페이스와 연결된 모든 장치는 인터럽트 요청(IRQ)을 통해 서로 통신합니다. 각 장치 큐는 보류 중인 IRQ를 보유하고 채널이라는 데이터 라인을 통해 서로 통신합니다. 대기열 유형은 특정 채널 유형과 연결되어 있습니다. 이러한 채널 유형은 다음과 같습니다.

  • 대기열 수신을 위한 RX
  • 전송 대기열을 위한 TX
  • 링크 인터럽트 또는 단일 SR-IOV(root input/output virtualization) 조정의 경우 기타
  • 하드웨어 용량 기반 다용도 채널 결합

15.1. nmcli를 사용하여 ethtool 오프로드 기능 구성

NetworkManager를 사용하여 연결 프로필에서 ethtool 오프로드 기능을 활성화하고 비활성화할 수 있습니다.

프로세스

  1. 예를 들어, RX 오프로드 기능을 활성화하고 enp1s0 연결 프로필에서 TX 오프로드를 비활성화하려면 다음을 입력합니다.

    # nmcli con modify enp1s0 ethtool.feature-rx on ethtool.feature-tx off
    Copy to Clipboard Toggle word wrap

    이 명령은 RX 오프로드를 명시적으로 활성화하고 TX 오프로드를 비활성화합니다.

    구성할 수 있는 설정 목록은 시스템의 nm-settings-nmcli(5) 도움말 페이지의 ethtool 설정 섹션을 참조하십시오.

  2. 이전에 활성화 또는 비활성화한 오프로드 기능의 설정을 제거하려면 기능의 매개변수를 null 값으로 설정합니다. 예를 들어 TX 오프로드의 구성을 제거하려면 다음을 입력합니다.

    # nmcli con modify enp1s0 ethtool.feature-tx ""
    Copy to Clipboard Toggle word wrap
  3. 네트워크 프로필을 다시 활성화합니다.

    # nmcli connection up enp1s0
    Copy to Clipboard Toggle word wrap

검증

  • ethtool -k 명령을 사용하여 네트워크 장치의 현재 오프로드 기능을 표시합니다.

    # ethtool -k network_device
    Copy to Clipboard Toggle word wrap

15.2. 네트워크 RHEL 시스템 역할을 사용하여 ethtool 오프로드 기능 구성

네트워크 인터페이스 컨트롤러는 TOE(TCP 오프로드 엔진)를 사용하여 특정 작업을 네트워크 컨트롤러에 오프로드할 수 있습니다. 이렇게 하면 네트워크 처리량이 향상됩니다. 네트워크 인터페이스의 연결 프로필에서 오프로드 기능을 구성합니다. Ansible 및 네트워크 RHEL 시스템 역할을 사용하면 이 프로세스를 자동화하고 플레이북에 정의된 호스트에서 연결 프로필을 원격으로 구성할 수 있습니다.

주의

네트워크 RHEL 시스템 역할을 사용하여 기존 연결 프로필의 특정 값만 업데이트할 수 없습니다. 이 역할은 연결 프로필이 플레이북의 설정과 정확히 일치하는지 확인합니다. 동일한 이름의 연결 프로필이 이미 존재하는 경우 역할은 플레이북의 설정을 적용하고 프로필의 다른 모든 설정을 기본값으로 재설정합니다. 값을 재설정하지 않으려면 변경하려는 설정을 포함하여 플레이북에서 네트워크 연결 프로필의 전체 구성을 항상 지정합니다.

사전 요구 사항

프로세스

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Configure the network
      hosts: managed-node-01.example.com
      tasks:
        - name: Ethernet connection profile with dynamic IP address settings and offload features
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.network
          vars:
            network_connections:
              - name: enp1s0
                type: ethernet
                autoconnect: yes
                ip:
                  dhcp4: yes
                  auto6: yes
                ethtool:
                  features:
                    gro: no
                    gso: yes
                    tx_sctp_segmentation: no
                state: up
    Copy to Clipboard Toggle word wrap

    예제 플레이북에 지정된 설정은 다음과 같습니다.

    Gro: no
    일반 수신 오프로드(GRO)를 비활성화합니다.
    GSO: yes
    GSO(Generic segmentation Off)를 활성화합니다.
    tx_sctp_segmentation: no
    TX 스트림 제어 전송 프로토콜(SCTP) 분할을 비활성화합니다.

    플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의 /usr/share/ansible/roles/rhel-system-roles.network/README.md 파일을 참조하십시오.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

검증

  • 관리 노드의 Ansible 팩트를 쿼리하고 오프로드 설정을 확인합니다.

    # ansible managed-node-01.example.com -m ansible.builtin.setup
    ...
            "ansible_enp1s0": {
                "active": true,
                "device": "enp1s0",
    	    "features": {
    	        ...
    		"rx_gro_hw": "off,
    	        ...
    		"tx_gso_list": "on,
    	        ...
    		"tx_sctp_segmentation": "off",
    		...
                }
    ...
    Copy to Clipboard Toggle word wrap

15.3. nmcli를 사용하여 ethtool 병합 설정 구성

NetworkManager를 사용하여 연결 프로필에서 ethtool 병합 설정을 설정할 수 있습니다.

프로세스

  1. 예를 들어 enp1s0 연결 프로필에서 지연할 수신 패킷의 최대 수를 128 으로 설정하려면 다음을 입력합니다.

    # nmcli connection modify enp1s0 ethtool.coalesce-rx-frames 128
    Copy to Clipboard Toggle word wrap

    구성할 수 있는 설정 목록은 시스템의 nm-settings-nmcli(5) 도움말 페이지의 ethtool 설정 섹션을 참조하십시오.

  2. 병합 설정을 제거하려면 이를 null 값으로 설정합니다. 예를 들어 ethtool.coalesce-rx-frames 설정을 제거하려면 다음을 입력합니다.

    # nmcli connection modify enp1s0 ethtool.coalesce-rx-frames ""
    Copy to Clipboard Toggle word wrap
  3. 네트워크 프로필을 다시 활성화하려면 다음을 수행합니다.

    # nmcli connection up enp1s0
    Copy to Clipboard Toggle word wrap

검증

  • ethtool -c 명령을 사용하여 네트워크 장치의 현재 오프로드 기능을 표시합니다.

    # ethtool -c <network_device>
    Copy to Clipboard Toggle word wrap

15.4. 네트워크 RHEL 시스템 역할을 사용하여 ethtool 병합 설정 구성

인터럽트 병합을 사용하면 시스템은 네트워크 패킷을 수집하고 여러 패킷에 대한 단일 인터럽트를 생성합니다. 이는 하나의 하드웨어 인터럽트를 사용하여 커널에 전송되는 데이터의 양을 증가시켜 인터럽트 부하를 줄이고 처리량을 극대화합니다. 네트워크 인터페이스의 연결 프로필에서 병합 설정을 구성합니다. Ansible 및 네트워크 RHEL 역할을 사용하면 이 프로세스를 자동화하고 플레이북에 정의된 호스트에서 연결 프로필을 원격으로 구성할 수 있습니다.

주의

네트워크 RHEL 시스템 역할을 사용하여 기존 연결 프로필의 특정 값만 업데이트할 수 없습니다. 이 역할은 연결 프로필이 플레이북의 설정과 정확히 일치하는지 확인합니다. 동일한 이름의 연결 프로필이 이미 존재하는 경우 역할은 플레이북의 설정을 적용하고 프로필의 다른 모든 설정을 기본값으로 재설정합니다. 값을 재설정하지 않으려면 변경하려는 설정을 포함하여 플레이북에서 네트워크 연결 프로필의 전체 구성을 항상 지정합니다.

사전 요구 사항

프로세스

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Configure the network
      hosts: managed-node-01.example.com
      tasks:
        - name: Ethernet connection profile with dynamic IP address settings and coalesce settings
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.network
          vars:
            network_connections:
              - name: enp1s0
                type: ethernet
                autoconnect: yes
                ip:
                  dhcp4: yes
                  auto6: yes
                ethtool:
                  coalesce:
                    rx_frames: 128
                    tx_frames: 128
                state: up
    Copy to Clipboard Toggle word wrap

    예제 플레이북에 지정된 설정은 다음과 같습니다.

    rx_frames: <value>
    RX 프레임 수를 설정합니다.
    gso: <value>
    TX 프레임 수를 설정합니다.

    플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의 /usr/share/ansible/roles/rhel-system-roles.network/README.md 파일을 참조하십시오.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

검증

  • 네트워크 장치의 현재 오프로드 기능을 표시합니다.

    # ansible managed-node-01.example.com -m command -a 'ethtool -c enp1s0'
    managed-node-01.example.com | CHANGED | rc=0 >>
    ...
    rx-frames:	128
    ...
    tx-frames:	128
    ...
    Copy to Clipboard Toggle word wrap

패킷 삭제 속도가 발생하면 이더넷 장치의 링 버퍼 크기를 늘리면 애플리케이션이 데이터 손실, 시간 초과 또는 기타 문제가 보고됩니다.

수신 링 버퍼는 장치 드라이버와 NIC(네트워크 인터페이스 컨트롤러) 간에 공유됩니다. 카드는 전송(TX)을 할당하고(RX) 링 버퍼를 수신합니다. 이름에서 알 수 있듯이 링 버퍼는 오버플로가 기존 데이터를 덮어쓰는 순환 버퍼입니다. NIC에서 커널로 데이터를 이동하는 두 가지 방법, 하드웨어 인터럽트 및 소프트웨어 인터럽트( softIRQs라고도 함)가 있습니다.

커널은 장치 드라이버가 이를 처리할 수 있을 때까지 RX 링 버퍼를 사용하여 들어오는 패킷을 저장합니다. 장치 드라이버는 일반적으로 SoftIRQs를 사용하여 RX 링을 드레이닝하여 들어오는 패킷을 sk_buff 또는 skb 라는 커널 데이터 구조에 배치하여 커널과 관련 소켓을 소유하는 애플리케이션까지 이동합니다.

커널은 TX 링 버퍼를 사용하여 네트워크로 전송해야 하는 발신 패킷을 보관합니다. 이러한 링 버퍼는 스택 하단에 있으며 패킷 드롭이 발생할 수 있는 중요한 지점이며 네트워크 성능에 부정적인 영향을 미칩니다.

프로세스

  1. 인터페이스의 패킷 삭제 통계를 표시합니다.

    # ethtool -S enp1s0
        ...
        rx_queue_0_drops: 97326
        rx_queue_1_drops: 63783
        ...
    Copy to Clipboard Toggle word wrap

    명령 출력은 네트워크 카드 및 드라이버에 따라 다릅니다.

    카운터 삭제 또는 삭제 카운터의 값이 높으면 사용 가능한 버퍼가 커널에서 패킷을 처리할 수 있는 것보다 더 빠르게 채워지는 것을 나타냅니다. 링 버퍼를 늘리면 이러한 손실을 방지하는 데 도움이 될 수 있습니다.

  2. 최대 링 버퍼 크기를 표시합니다.

    # ethtool -g enp1s0
     Ring parameters for enp1s0:
     Pre-set maximums:
     RX:             4096
     RX Mini:        0
     RX Jumbo:       16320
     TX:             4096
     Current hardware settings:
     RX:             255
     RX Mini:        0
     RX Jumbo:       0
     TX:             255
    Copy to Clipboard Toggle word wrap

    사전 설정 최대값 섹션의 값이 현재 하드웨어 설정 섹션보다 크면 다음 단계의 설정을 변경할 수 있습니다.

  3. 인터페이스를 사용하는 NetworkManager 연결 프로필을 확인합니다.

    # nmcli connection show
    NAME                UUID                                  TYPE      DEVICE
    Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0
    Copy to Clipboard Toggle word wrap
  4. 연결 프로필을 업데이트하고 링 버퍼를 늘립니다.

    • RX 링 버퍼를 늘리려면 다음을 입력합니다.

      # nmcli connection modify Example-Connection ethtool.ring-rx 4096
      Copy to Clipboard Toggle word wrap
    • TX 링 버퍼를 늘리려면 다음을 입력합니다.

      # nmcli connection modify Example-Connection ethtool.ring-tx 4096
      Copy to Clipboard Toggle word wrap
  5. NetworkManager 연결을 다시 로드합니다.

    # nmcli connection up Example-Connection
    Copy to Clipboard Toggle word wrap
    중요

    NIC가 사용하는 드라이버에 따라 링 버퍼에서 변경하면 곧 네트워크 연결이 중단될 수 있습니다.

패킷 삭제 속도가 발생하면 이더넷 장치의 링 버퍼 크기를 늘리면 애플리케이션이 데이터 손실, 시간 초과 또는 기타 문제가 보고됩니다.

링 버퍼는 오버플로가 기존 데이터를 덮어쓰는 순환 버퍼입니다. 네트워크 카드는 전송(TX)을 할당하고(RX) 링 버퍼를 수신합니다. 수신 링 버퍼는 장치 드라이버와 NIC(네트워크 인터페이스 컨트롤러) 간에 공유됩니다. 데이터는 SoftIRQs라고도 하는 하드웨어 인터럽트 또는 소프트웨어 인터럽트를 통해 NIC에서 커널로 이동할 수 있습니다.

커널은 장치 드라이버가 이를 처리할 수 있을 때까지 RX 링 버퍼를 사용하여 들어오는 패킷을 저장합니다. 장치 드라이버는 일반적으로 SoftIRQs를 사용하여 RX 링을 드레이닝하여 들어오는 패킷을 sk_buff 또는 skb 라는 커널 데이터 구조에 배치하여 커널과 관련 소켓을 소유하는 애플리케이션까지 이동합니다.

커널은 TX 링 버퍼를 사용하여 네트워크로 전송해야 하는 발신 패킷을 보관합니다. 이러한 링 버퍼는 스택 하단에 있으며 패킷 드롭이 발생할 수 있는 중요한 지점이며 네트워크 성능에 부정적인 영향을 미칩니다.

NetworkManager 연결 프로필에서 링 버퍼 설정을 구성합니다. Ansible 및 네트워크 RHEL 시스템 역할을 사용하면 이 프로세스를 자동화하고 플레이북에 정의된 호스트에서 연결 프로필을 원격으로 구성할 수 있습니다.

주의

네트워크 RHEL 시스템 역할을 사용하여 기존 연결 프로필의 특정 값만 업데이트할 수 없습니다. 이 역할은 연결 프로필이 플레이북의 설정과 정확히 일치하는지 확인합니다. 동일한 이름의 연결 프로필이 이미 존재하는 경우 역할은 플레이북의 설정을 적용하고 프로필의 다른 모든 설정을 기본값으로 재설정합니다. 값을 재설정하지 않으려면 변경하려는 설정을 포함하여 플레이북에서 네트워크 연결 프로필의 전체 구성을 항상 지정합니다.

사전 요구 사항

  • 컨트롤 노드 및 관리형 노드를 준비했습니다.
  • 관리 노드에서 플레이북을 실행할 수 있는 사용자로 제어 노드에 로그인되어 있습니다.
  • 관리 노드에 연결하는 데 사용하는 계정에는 sudo 권한이 있습니다.
  • 장치가 지원하는 최대 링 버퍼 크기를 알고 있습니다.

프로세스

  1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

    ---
    - name: Configure the network
      hosts: managed-node-01.example.com
      tasks:
        - name: Ethernet connection profile with dynamic IP address setting and increased ring buffer sizes
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.network
          vars:
            network_connections:
              - name: enp1s0
                type: ethernet
                autoconnect: yes
                ip:
                  dhcp4: yes
                  auto6: yes
                ethtool:
                  ring:
                    rx: 4096
                    tx: 4096
                state: up
    Copy to Clipboard Toggle word wrap

    예제 플레이북에 지정된 설정은 다음과 같습니다.

    rx: <value>
    수신된 최대 링 버퍼 항목 수를 설정합니다.
    TX: &lt ;value>
    전송된 최대 링 버퍼 항목 수를 설정합니다.

    플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의 /usr/share/ansible/roles/rhel-system-roles.network/README.md 파일을 참조하십시오.

  2. 플레이북 구문을 확인합니다.

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard Toggle word wrap

    이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

  3. Playbook을 실행합니다.

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard Toggle word wrap

검증

  • 최대 링 버퍼 크기를 표시합니다.

    # ansible managed-node-01.example.com -m command -a 'ethtool -g enp1s0'
    managed-node-01.example.com | CHANGED | rc=0 >>
    ...
    Current hardware settings:
    RX:             4096
    RX Mini:        0
    RX Jumbo:       0
    TX:             4096
    Copy to Clipboard Toggle word wrap

15.7. nmcli를 사용하여 ethtool 채널 설정 구성

NetworkManager를 사용하면 네트워크 장치 및 연결을 관리할 수 있습니다. ethtool 유틸리티는 네트워크 인터페이스 카드의 링크 속도 및 관련 설정을 관리합니다. ethtool 은 연결된 장치와 IRQ 기반 통신을 처리하여 연결 프로필의 관련 채널 설정을 관리합니다.

프로세스

  1. 네트워크 장치와 연결된 채널을 표시합니다.

    # ethtool --show-channels enp1s0
    Channel parameters for enp1s0:
    Pre-set maximums:
    RX:		4
    TX:		3
    Other:	   10
    Combined:  63
    
    Current hardware settings:
    RX:   	 1
    TX:   	 1
    Other:   1
    Combined:  1
    Copy to Clipboard Toggle word wrap
  2. 네트워크 인터페이스의 채널 설정을 업데이트합니다.

    # nmcli connection modify enp1s0 ethtool.channels-rx 4 ethtool.channels-tx 3 ethtools.channels-other 9 ethtool.channels-combined 50
    Copy to Clipboard Toggle word wrap
  3. 네트워크 프로필을 다시 활성화합니다.

    # nmcli connection up enp1s0
    Copy to Clipboard Toggle word wrap

검증

  • 네트워크 장치와 관련된 업데이트된 채널 설정을 확인합니다.

    # ethtool --show-channels enp1s0
    Channel parameters for enp1s0:
    Pre-set maximums:
    RX:		4
    TX:		3
    Other:	  10
    Combined: 63
    
    Current hardware settings:
    RX:   	 4
    TX:   	 3
    Other:   9
    Combined:  50
    Copy to Clipboard Toggle word wrap

16장. NetworkManager 디버깅 소개

모든 또는 특정 도메인의 로그 수준을 늘리면 NetworkManager가 수행하는 작업에 대한 자세한 정보를 기록하는 데 도움이 됩니다. 이 정보를 사용하여 문제를 해결할 수 있습니다. NetworkManager는 로깅 정보를 생성하기 위해 다양한 수준과 도메인을 제공합니다. /etc/NetworkManager/NetworkManager.conf 파일은 NetworkManager의 기본 구성 파일입니다. 로그는 저널에 저장됩니다.

16.1. NetworkManager 다시 적용 방법 소개

NetworkManager 서비스는 프로필을 사용하여 장치의 연결 설정을 관리합니다. 데스크탑 버스(D-Bus) API는 이러한 연결 설정을 생성, 수정 및 삭제할 수 있습니다. 프로필 변경에 대해 D-Bus API는 기존 설정을 연결의 수정된 설정에 복제합니다. 복제에도 불구하고 수정된 설정에 변경 사항이 적용되지 않습니다. 이를 적용하려면 연결의 기존 설정을 다시 활성화하거나 reapply() 메서드를 사용합니다.

reapply() 메서드에는 다음과 같은 기능이 있습니다.

  • 네트워크 인터페이스를 비활성화하거나 다시 시작하지 않고 수정된 연결 설정을 업데이트합니다.
  • 수정된 연결 설정에서 보류 중인 변경 사항 제거. NetworkManager 는 수동 변경 사항을 되돌리지 않으므로 장치를 재구성하고 외부 또는 수동 매개 변수를 되돌릴 수 있습니다.
  • 기존 연결 설정과 다른 수정된 연결 설정 생성.

또한 reapply() 메서드는 다음 특성을 지원합니다.

  • bridge.ageing-time
  • bridge.forward-delay
  • bridge.group-address
  • bridge.group-forward-mask
  • bridge.hello-time
  • bridge.max-age
  • bridge.multicast-hash-max
  • bridge.multicast-last-member-count
  • bridge.multicast-last-member-interval
  • bridge.multicast-membership-interval
  • bridge.multicast-querier
  • bridge.multicast-querier-interval
  • bridge.multicast-query-interval
  • bridge.multicast-query-response-interval
  • bridge.multicast-query-use-ifaddr
  • bridge.multicast-router
  • bridge.multicast-snooping
  • bridge.multicast-startup-query-count
  • bridge.multicast-startup-query-interval
  • bridge.priority
  • bridge.stp
  • bridge.VLAN-filtering
  • bridge.VLAN-protocol
  • bridge.VLANs
  • 802-3-ethernet.accept-all-mac-addresses
  • 802-3-ethernet.cloned-mac-address
  • IPv4.addresses
  • IPv4.dhcp-client-id
  • IPv4.dhcp-iaid
  • IPv4.dhcp-timeout
  • IPv4.DNS
  • IPv4.DNS-priority
  • IPv4.DNS-search
  • IPv4.gateway
  • IPv4.ignore-auto-DNS
  • IPv4.ignore-auto-routes
  • IPv4.may-fail
  • IPv4.method
  • IPv4.never-default
  • IPv4.route-table
  • IPv4.routes
  • IPv4.routing-rules
  • IPv6.addr-gen-mode
  • IPv6.addresses
  • IPv6.dhcp-duid
  • IPv6.dhcp-iaid
  • IPv6.dhcp-timeout
  • IPv6.DNS
  • IPv6.DNS-priority
  • IPv6.DNS-search
  • IPv6.gateway
  • IPv6.ignore-auto-DNS
  • IPv6.may-fail
  • IPv6.method
  • IPv6.never-default
  • IPv6.ra-timeout
  • IPv6.route-metric
  • IPv6.route-table
  • IPv6.routes
  • IPv6.routing-rules

16.2. NetworkManager 로그 수준 설정

기본적으로 모든 로그 도메인은 INFO 로그 수준을 기록하도록 설정됩니다. 디버그 로그를 수집하기 전에 속도 제한을 비활성화합니다. rate-limiting을 사용하면 짧은 시간에 너무 많은 메시지가 표시되면 systemd-journald 가 메시지를 삭제합니다. 이는 로그 수준이 TRACE 인 경우 발생할 수 있습니다.

이 절차에서는 rate-limiting을 비활성화하고 all (ALL) 도메인에 대해 디버그 로그를 기록할 수 있습니다.

프로세스

  1. rate-limiting을 비활성화하려면 /etc/systemd/journald.conf 파일을 편집하고 [Journal] 섹션에서 RateLimitBurst 매개변수의 주석을 제거하고 해당 값을 0:로 설정합니다.

    RateLimitBurst=0
    Copy to Clipboard Toggle word wrap
  2. systemd-journald 서비스를 다시 시작합니다.

    # systemctl restart systemd-journald
    Copy to Clipboard Toggle word wrap
  3. 다음 콘텐츠를 사용하여 /etc/NetworkManager/conf.d/95-nm-debug.conf 파일을 만듭니다.

    [logging]
    domains=ALL:TRACE
    Copy to Clipboard Toggle word wrap

    domain 매개변수는 쉼표로 구분된 여러 domain:level 쌍을 포함할 수 있습니다.

  4. NetworkManager 서비스를 다시 시작합니다.

    # systemctl restart NetworkManager
    Copy to Clipboard Toggle word wrap

검증

  • systemd 저널을 쿼리하여 NetworkManager 장치의 저널 항목을 표시합니다.

    # journalctl -u NetworkManager
    ...
    Jun 30 15:24:32 server NetworkManager[164187]: <debug> [1656595472.4939] active-connection[0x5565143c80a0]: update activation type from assume to managed
    Jun 30 15:24:32 server NetworkManager[164187]: <trace> [1656595472.4939] device[55b33c3bdb72840c] (enp1s0): sys-iface-state: assume -> managed
    Jun 30 15:24:32 server NetworkManager[164187]: <trace> [1656595472.4939] l3cfg[4281fdf43e356454,ifindex=3]: commit type register (type "update", source "device", existing a369f23014b9ede3) -> a369f23014b9ede3
    Jun 30 15:24:32 server NetworkManager[164187]: <info>  [1656595472.4940] manager: NetworkManager state is now CONNECTED_SITE
    ...
    Copy to Clipboard Toggle word wrap

16.3. nmcli를 사용하여 런타임에 로그 수준을 일시적으로 설정

nmcli 를 사용하여 런타임에 로그 수준을 변경할 수 있습니다.

프로세스

  1. 선택 사항: 현재 로깅 설정을 표시합니다.

    # nmcli general logging
      LEVEL  DOMAINS
      INFO   PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,WIFI_SCAN,IP4,IP6,A
    UTOIP4,DNS,VPN,SHARING,SUPPLICANT,AGENTS,SETTINGS,SUSPEND,CORE,DEVICE,OLPC,
    WIMAX,INFINIBAND,FIREWALL,ADSL,BOND,VLAN,BRIDGE,DBUS_PROPS,TEAM,CONCHECK,DC
    B,DISPATCH
    Copy to Clipboard Toggle word wrap
  2. 로깅 수준 및 도메인을 수정하려면 다음 옵션을 사용합니다.

    • 모든 도메인의 로그 수준을 동일한 LEVEL 으로 설정하려면 다음을 입력합니다.

      # nmcli general logging level LEVEL domains ALL
      Copy to Clipboard Toggle word wrap
    • 특정 도메인의 수준을 변경하려면 다음을 입력합니다.

      # nmcli general logging level LEVEL domains DOMAINS
      Copy to Clipboard Toggle word wrap

      이 명령을 사용하여 로깅 수준을 업데이트하면 다른 모든 도메인에 대한 로깅이 비활성화됩니다.

    • 특정 도메인의 수준을 변경하고 다른 모든 도메인의 수준을 유지하려면 다음을 입력합니다.

      # nmcli general logging level KEEP domains DOMAIN:LEVEL,DOMAIN:LEVEL
      Copy to Clipboard Toggle word wrap

16.4. NetworkManager 로그 보기

문제 해결을 위해 NetworkManager 로그를 볼 수 있습니다.

프로세스

  • 로그를 보려면 다음을 입력합니다.

    # journalctl -u NetworkManager -b
    Copy to Clipboard Toggle word wrap

16.5. 디버깅 수준 및 도메인

levels 및 domain 매개변수를 사용하여 NetworkManager에 대한 디버깅을 관리할 수 있습니다. 수준은 상세 정보 수준을 정의하는 반면, 도메인은 심각도가 지정된 (level) 로그를 기록할 메시지의 범주를 정의합니다.

Expand
로그 수준설명

OFF

NetworkManager에 대한 메시지를 기록하지 않음

ERR

심각한 오류만 로그

WARN

작업을 반영할 수 있는 경고 로그

INFO

상태 및 작업 추적에 유용한 다양한 정보 메시지를 기록합니다.

DEBUG

디버깅을 위해 상세 로깅 활성화

TRACE

DEBUG 수준보다 더 자세한 로깅 활성화

후속 수준은 이전 수준의 모든 메시지를 기록합니다. 예를 들어 로그 수준을 INFO 로 설정하면 ERRWARN 로그 수준에 포함된 메시지도 로깅됩니다.

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동