검색

34.6. UDP 연결 튜닝

download PDF

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

34.6.1. 패킷 삭제 탐지

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

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

참고

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

절차

  1. NIC(네트워크 인터페이스 컨트롤러)가 패킷을 삭제하는지 여부를 확인합니다.

    1. NIC 및 드라이버별 통계를 표시합니다.

      # ethtool -S enp1s0
      NIC statistics:
           ...
           rx_queue_0_drops: 17657
           ...

      통계 이름 및 사용 가능한 경우 NIC와 드라이버에 따라 다릅니다.

    2. 인터페이스 통계를 표시합니다.

      # 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
          link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
          RX:   bytes  packets errors dropped  missed   mcast_
          84697611107 56866482      0   10904       0       0
          TX:   bytes  packets errors dropped carrier collsns_
           5540028184  3722234      0       0       0       0

      RX 는 수신된 패킷의 통계와 전송된 패킷의 TX 를 나타냅니다.

  2. 소켓 버퍼가 너무 느리거나 애플리케이션 처리 속도가 느리기 때문에 UDP 프로토콜 특정 패킷을 식별합니다.

    # nstat -az UdpSndbufErrors UdpRcvbufErrors
    #kernel
    UdpSndbufErrors           4    0.0
    UdpRcvbufErrors    45716659    0.0

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

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

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

참고

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

사전 요구 사항

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

절차

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

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

    1. 최대 UDP 소켓 읽기 버퍼 크기를 표시하고 다음 값을 기록해 둡니다.

      # sysctl net.core.rmem_max
      net.core.rmem_max = 16777216

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

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

      # firewall-cmd --add-port=5201/tcp --add-port=5201/udp
      # firewall-cmd --reload

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

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

      # iperf3 --server

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

  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
      ...
    2. 최대 UDP 소켓 쓰기 버퍼 크기를 표시하고 값을 기록해 둡니다.

      # sysctl net.core.wmem_max
      net.core.wmem_max = 16777216

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

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

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

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

      • --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

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

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

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

      # firewall-cmd --remove-port=5201/tcp --remove-port=5201/udp
      # firewall-cmd --reload

추가 리소스

  • iperf3(1) 매뉴얼 페이지

34.6.3. UDP 트래픽 처리량에 대한 MTU 크기의 영향

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

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

중요

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

연결 유형에 따라 특정 MTU 제한 사항이 있습니다.

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

34.6.4. UDP 트래픽 처리량에 대한 CPU 속도 영향

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

예를 들어, MTU(Maximum Transmission Unit) 및 대용량 소켓 버퍼가 있는 tuned 호스트에서 3GbE CPU는 완전한 속도로 UDP 트래픽을 전송하거나 수신하는 10GB NIC의 트래픽을 처리할 수 있습니다. 그러나 UDP 트래픽을 전송할 때 3개 미만의 CPU 속도당 약 2Gbps의 속도 손실이 발생할 것으로 예상할 수 있습니다. 또한 3Gbps의 CPU 속도가 10Gbps를 달성할 수 있는 경우 동일한 CPU는 40GB NIC에서 UDP 트래픽을 약 20-25Gbps로 제한합니다.

34.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

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

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

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

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

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

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

검증

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

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

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.