検索

31.6. UDP 接続のチューニング

download PDF

UDP トラフィックのスループットを向上させるために Red Hat Enterprise Linux のチューニングを開始する前に、現実的に想定することが重要です。UDP は単純なプロトコルです。TCP と比較すると、UDP にはフロー制御、輻輳制御、データ信頼性などの機能が含まれていません。このため、ネットワークインターフェイスコントローラー (NIC) の最大速度に近いスループットレートで、UDP 経由で信頼性の高い通信を実現することが困難になります。

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

    出力の 2 番目の列にはカウンターがリストされます。

関連情報

31.6.2. iperf3 を使用した UDP スループットのテスト

iperf3 ユーティリティーは、サーバーモードとクライアントモードを提供し、2 つのホスト間のネットワークスループットテストを実行します。

注記

アプリケーションのスループットは、アプリケーションが使用するバッファーサイズなど、多くの要因に依存します。したがって、iperf3 などのテストユーティリティーで測定された結果は、実稼働ワークロード下のサーバー上のアプリケーションの結果とは大きく異なる可能性があります。

前提条件

  • iperf3 パッケージはクライアントとサーバーの両方にインストールされている。
  • 両方のホスト上の他のサービスによって、テスト結果に大きな影響を与えるネットワークトラフィックが発生することはない。
  • オプション: サーバーとクライアントの両方で最大 UDP ソケットサイズを増やしている。詳細は、Increasing the system-wide UDP socket buffers を参照してください。

手順

  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 ヘッダー (IPv4 の場合は 20 バイト、IPv6 の場合は 40 バイト) - 8 バイトの UDP ヘッダー。
      • --bitrate <rate>: ビットレートをビット/秒単位で指定した値に制限します。2 Gbps の場合は 2G など、単位を指定できます。

        このパラメーターを機能すると予想される値に設定し、後の測定で値を増やします。サーバーが、送信パス上のデバイスよりも速い速度で、またはクライアントが処理できるよりも速い速度でパケットを送信する場合、パケットがドロップされる可能性があります。

      • --client <server>: クライアントモードを有効にし、iperf3 サーバーを実行するサーバーの IP アドレスまたは名前を設定します。
  4. iperf3 がテストを完了するまで待ちます。サーバーとクライアントの両方で統計が毎秒表示され、最後に概要が表示されます。たとえば、以下はクライアントに表示される概要です。

    [ 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

    この例では、平均ビットレートは 2 Gbps で、パケットの損失はありませんでした。

  5. サーバーの場合:

    1. Ctrl+C を押して iperf3 サーバーを停止します。
    2. firewalld のポート 5201 を閉じます。

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

関連情報

  • iperf3(1) man ページ

31.6.3. UDP トラフィックスループットに対する MTU サイズの影響

アプリケーションが大きな UDP メッセージサイズを使用する場合、ジャンボフレームを使用するとスループットを改善できます。IEEE 802.3 標準によれば、仮想ローカルエリアネットワーク (VLAN) タグのないデフォルトのイーサネットフレームの最大サイズは 1518 バイトです。これらの各フレームには 18 バイトのヘッダーが含まれて、ペイロード用に 1500 バイトが残されます。したがって、サーバーがネットワーク経由で送信するデータの 1500 バイトごとに、18 バイト (1.2%) がオーバーヘッドになります。

ジャンボフレームは、標準のイーサネットペイロードサイズである 1500 バイトよりも大きな最大伝送単位 (MTU) を持つ非標準フレームです。たとえば、最大許容 MTU が 9000 バイトのペイロードでジャンボフレームを設定すると、各フレームのオーバーヘッドは 0.2% に減少します。

重要

伝送パス上のすべてのネットワークデバイスと関連するブロードキャストドメインは、ジャンボフレームをサポートし、同じ MTU を使用する必要があります。伝送パス上の一貫性のない MTU 設定によるパケットの断片化と再構築により、ネットワークスループットが低下します。

接続の種類によっては、特定の MTU 制限があります。

  • イーサネット: MTU は 9000 バイトに制限されます。
  • データグラムモードの IP over InfiniBand (IPoIB): MTU は、InfiniBand MTU より 4 バイト小さい値に制限されます。
  • インメモリーネットワークは通常、より大きな MTU をサポートします。詳細については、それぞれのドキュメントを参照してください。

31.6.4. UDP トラフィックスループットに対する CPU 速度の影響

バルク転送では、UDP プロトコルは TCP よりも効率が大幅に低くなります。これは、主に UDP でのパケット集約が欠落しているためです。デフォルトでは、Generic Receive Offload (GRO) および Transmit Segmentation Offload (TSO) 機能は有効になっていません。その結果、CPU 周波数によって、高速リンクでのバルク転送の UDP スループットが制限される可能性があります。

たとえば、高い最大伝送単位 (MTU) と大きなソケットバッファーを備えたチューニングされたホストでは、3 GHz CPU が、UDP トラフィックをフルスピードで送受信する 10 GBit NIC のトラフィックを処理できます。ただし、UDP トラフィックを送信する場合は、3 GHz 未満の CPU 速度 100 MHz ごとに約 1 - 2 Gbps の速度低下が予想されます。また、3 GHz の CPU 速度がほぼ 10 Gbps に達する場合、同じ CPU は 40 GBit NIC 上の UDP トラフィックを約 20 - 25 Gbps に制限します。

31.6.5. システム全体の UDP ソケットバッファーの増加

ソケットバッファーには、カーネルが受信したデータ、または送信する必要があるデータが一時的に保存されます。

  • 読み取りソケットバッファーには、カーネルが受信したがアプリケーションがまだ読み取っていないパケットが保持されます。
  • 書き込みソケットバッファーには、アプリケーションがバッファーに書き込んだものの、カーネルがまだ IP スタックとネットワークドライバーに渡していないパケットが保持されます。

UDP パケットが大きすぎてバッファーサイズを超えている場合、またはパケットの送受信速度が速すぎる場合、カーネルはデータがバッファーから削除されるまで、新しい受信 UDP パケットをドロップします。この場合、ソケットバッファーを増やすことでパケットロスを防ぐことができます。

重要

バッファーサイズを大きすぎる設定にすると、メモリーが無駄に消費されます。各ソケットはアプリケーションが要求するサイズに設定でき、カーネルはこの値を 2 倍にします。たとえば、アプリケーションが 256 KiB のソケットバッファーサイズを要求し、100 万個のソケットを開く場合、システムは潜在的なソケットバッファースペースとしてのみ 512 GB RAM (512 KiB x 100 万) を必要とします。

前提条件

  • かなりの割合で UDP パケットがドロップされました。

手順

  1. /etc/sysctl.d/10-udp-socket-buffers.conf ファイルを作成し、要件に基づいて最大読み取りバッファーサイズまたは書き込みバッファーサイズ、あるいはその両方を設定します。

    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216

    値をバイト単位で指定します。この例の値は、バッファーの最大サイズを 16 MiB に設定します。両方のパラメーターのデフォルト値は 212992 バイト (208 KiB) です。

  2. /etc/sysctl.d/10-udp-socket-buffers.conf ファイルから設定をロードします。

    # sysctl -p /etc/sysctl.d/10-udp-socket-buffers.conf
  3. より大きなソケットバッファーサイズを使用するようにアプリケーションを設定します。

    net.core.rmem_max および net.core.wmem_max パラメーターは、アプリケーションの setsockopt() 関数が要求できる最大バッファーサイズを定義します。setsockopt() 関数を使用しないようにアプリケーションを設定すると、カーネルは rmem_default および wmem_default パラメーターの値を使用することに注意してください。

    詳細については、アプリケーションのプログラミング言語のドキュメントを参照してください。アプリケーションの開発者ではない場合は、開発者にお問い合わせください。

  4. 新しい UDP バッファーサイズを使用するには、アプリケーションを再起動します。

検証

  • パケットドロップが発生したときに使用したのと同じ方法を使用して、パケットドロップ統計を監視します。

    パケットドロップが依然として発生するが、レートが低い場合は、バッファーサイズをさらに増やします。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.