ネットワークのトラブルシューティングとパフォーマンスチューニング

手順

1. インターフェイスのパケットドロップ統計を表示します。

   # ethtool -S enp1s0
       ...
       rx_queue_0_drops: 97326
       rx_queue_1_drops: 63783
       ...

   コマンドの出力は、ネットワークカードとドライバーに依存することに注意してください。

   discard または drop カウンターの値が高い場合は、カーネルがパケットを処理できるよりも速く、使用可能なバッファーがいっぱいになることを示します。リングバッファーを増やすと、このような損失を回避できます。

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

   Pre-set maximums セクションの値が Current hardware settings セクションよりも高い場合は、次の手順で設定を変更できます。

3. このインターフェイスを使用する NetworkManager 接続プロファイルを特定します。

   # nmcli connection show
   NAME                UUID                                  TYPE      DEVICE
   Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0

4. 接続プロファイルを更新し、リングバッファーを増やします。

   • RX リングバッファーを増やすには、次のように実行します。

     # nmcli connection modify Example-Connection ethtool.ring-rx 4096

   • TX リングバッファーを増やすには、次のように実行します。

     # nmcli connection modify Example-Connection ethtool.ring-tx 4096

5. NetworkManager 接続をリロードします。

   # nmcli connection up Example-Connection

   重要

   NIC が使用するドライバーによっては、リングバッファーを変更すると、ネットワーク接続が短時間中断されることがあります。

手順

1. 次の内容を含む Playbook ファイル (例: ~/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

   サンプル Playbook で指定されている設定は次のとおりです。

   rx: <value>

   受信するリングバッファーエントリーの最大数を設定します。

   tx: <value>

   送信するリングバッファーエントリーの最大数を設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

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

   この awk コマンドは、/proc/net/softnet_stat の値を 16 進形式から 10 進形式に変換し、表形式で表示します。各行は、コア 0 から始まる CPU コアを表します。

   関連する列は次のとおりです。

   • 最初の列: 受信フレームの総数
   • 2 番目の列: バックログキューがいっぱいであるためにドロップされたフレームの数
   • 最後の列: CPU コア番号

2. /proc/net/softnet_stat ファイルの 2 番目の列の値が時間の経過とともに増加する場合は、バックログキューのサイズを増やします。

   1. 現在のバックログキューのサイズを表示します。

      # sysctl net.core.netdev_max_backlog
      net.core.netdev_max_backlog = 1000

   2. 次の内容を含む /etc/sysctl.d/10-netdev_max_backlog.conf ファイルを作成します。

      net.core.netdev_max_backlog = 2000

      net.core.netdev_max_backlog パラメーターを現在の値の 2 倍に設定します。

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

      # sysctl -p /etc/sysctl.d/10-netdev_max_backlog.conf

手順

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

   この例では、enp1s0 インターフェイスの送信キューの長さ (qlen) は 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)
   ...

3. 送信エラー数が多い、または増加している場合は、送信キューの長さをより長く設定します。

   1. このインターフェイスを使用する NetworkManager 接続プロファイルを特定します。

      # nmcli connection show
      NAME                UUID                                  TYPE      DEVICE
      Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0

   2. 接続プロファイルを更新し、送信キューの長さを増やします。

      # nmcli connection modify Example-Connection link.tx-queue-length 2000

      キューの長さを現在の値の 2 倍に設定します。

   3. 変更を適用します。

      # nmcli connection up Example-Connection

検証

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

2. ドロップされたパケットカウンターを監視します。

   # tc -s qdisc show dev enp1s0

   dropped カウンターがまだ増加する場合は、送信キューの長さを再度 2 倍にします。カウンターが増加しなくなるまで、このプロセスを繰り返します。

手順

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

   この awk コマンドは、/proc/net/softnet_stat の値を 16 進形式から 10 進形式に変換し、表形式で表示します。各行は、コア 0 から始まる CPU コアを表します。

   関連する列は次のとおりです。

   • 最初の列: 受信フレームの総数。
   • 3 番目の列: 1 回の NAPI ポーリングサイクルでインターフェイスからすべてのパケットを取得できなかった softirqd プロセスの回数。
   • 最後の列: CPU コア番号。

2. /proc/net/softnet_stat ファイルの 3 番目の列のカウンターが、時間の経過とともに増加する場合は、システムをチューニングします。

   1. net.core.netdev_budget_usecs および net.core.netdev_budget パラメーターの現在の値を表示します。

      # sysctl net.core.netdev_budget_usecs net.core.netdev_budget
      net.core.netdev_budget_usecs = 2000
      net.core.netdev_budget = 300

      これらの設定を使用すると、softirqd プロセスは、1 回のポーリングサイクルで、NIC から最大 300 個のメッセージを処理するのに最大 2000 マイクロ秒あります。ポーリングは、どの条件が最初に満たされたかに基づいて終了します。

   2. 次の内容を含む /etc/sysctl.d/10-netdev_budget.conf ファイルを作成します。

      net.core.netdev_budget = 600
      net.core.netdev_budget_usecs = 4000

      パラメーターを現在の値の 2 倍に設定します。

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

      # sysctl -p /etc/sysctl.d/10-netdev_budget.conf

手順

1. アクティブなプロファイルを表示します。

   # tuned-adm active
   Current active profile: network-latency

2. カスタム TuneD プロファイル用のディレクトリーを作成します。

   # mkdir /etc/tuned/network-latency-custom/

3. 次の内容を含む /etc/tuned/network-latency-custom/tuned.conf ファイルを作成します。

   [main]
   include=network-latency
   
   [cpu]
   force_latency=cstate.id:1|2

   このカスタムプロファイルは、network-latency プロファイルからすべての設定を継承します。force_latency TuneD パラメーターは、遅延をマイクロ秒 (µs) 単位で指定します。指定した値よりも C ステートのレイテンシーが高い場合、Red Hat Enterprise Linux のドライバーにより、CPU がより高い C ステートに移行するのが防止されます。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

手順

1. システムが使用するアイドル状態のドライバーを表示します。

   # cat /sys/devices/system/cpu/cpuidle/current_driver
   intel_idle

   ドライバーの詳細は、kernel-doc パッケージによって提供される /usr/share/doc/kernel-doc-<version>/Documentation/admin-guide/pm/cpuidle.rst ファイルを参照してください。

2. ホストが intel_idle ドライバーを使用している場合は、intel_idle.max_cstate カーネルパラメーターを設定して、CPU コアが使用できる最大の C ステートを定義します。

   # grubby --update-kernel=ALL --args="intel_idle.max_cstate=0"

   intel_idle.max_cstate=0 を設定すると、intel_idle ドライバーが無効になります。その結果、カーネルが acpi_idle ドライバーを使用するようになります。このドライバーは、EFI ファームウェアに設定されている C ステート値を使用します。そのため、これらの C ステート設定をオーバーライドするには、processor.max_cstate も設定してください。

3. すべてのホスト上で、CPU ベンダーに関係なく、CPU コアが使用できる最大の C ステートを設定します。

   # grubby --update-kernel=ALL --args="processor.max_cstate=0"

   重要

   intel_idle.max_cstate=0 に加えて processor.max_cstate=0 を設定すると、acpi_idle ドライバーは processor.max_cstate の値をオーバーライドして 1 に設定します。その結果、processor.max_cstate=0 intel_idle.max_cstate=0 の場合、カーネルが使用する最大の C ステートは C0 ではなく C1 になります。

4. 変更を有効にするためにホストを再起動します。

   # reboot

検証

1. 最大の C ステートを表示します。

   # cat /sys/module/processor/parameters/max_cstate
   1

2. ホストが intel_idle ドライバーを使用している場合は、最大の C ステートを表示します。

   # cat /sys/module/intel_idle/parameters/max_cstate
   0

手順

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

2. オプション: NetworkManager 接続プロファイルを表示します。

   # nmcli connection show
   NAME     UUID                                  TYPE      DEVICE
   Example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
   ...

3. 不一致の MTU を使用してネットワークへの接続を管理するプロファイルに MTU を設定します。

   # nmcli connection modify Example mtu 9000

4. 接続を再度アクティベートします。

   # nmcli connection up Example

検証

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

2. 伝送パス上にパケットを断片化するホストがないことを確認します。

   • 受信側で、カーネルの IP 再構築統計を表示します。

     # nstat -az IpReasm*
     #kernel
     IpReasmTimeout 0 0.0
     IpReasmReqds 0 0.0
     IpReasmOKs 0 0.0
     IpReasmFails 0 0.0

     カウンターが 0 を返した場合、パケットは再構築されていません。

   • 送信者側で、prohibit-fragmentation-bit を指定して ICMP リクエストを送信します。

     # ping -c1 -Mdo -s 8972 destination_host

     コマンドが成功した場合、パケットは断片化されていません。

     -s パケットサイズオプションの値を次のように計算します。MTU サイズ - 8 バイト ICMP ヘッダー - 20 バイト IPv4 ヘッダー = パケットサイズ

手順

1. オプション: サーバーとクライアントの両方のネットワークインターフェイスコントローラー (NIC) の最大ネットワーク速度を表示します。

   # ethtool enp1s0 | grep "Speed"
      Speed: 100000Mb/s

2. サーバー上では以下の設定になります。

   1. firewalld サービスでデフォルトの iperf3 TCP ポート 5201 を一時的に開きます。

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

   2. iperf3 をサーバーモードで起動します。

      # iperf3 --server

      サービスは現在、受信クライアント接続を待機しています。

3. クライアントで以下を実行します。

   1. スループットの測定を開始します。

      # iperf3 --time 60 --zerocopy --client 192.0.2.1

      • --time <seconds>: クライアントが送信を停止する時間を秒単位で定義します。

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

      • --zerocopy: write() システムコールを使用する代わりに、ゼロコピーメソッドを有効にします。このオプションは、ゼロコピー対応アプリケーションをシミュレートする場合、または単一ストリームで 40 Gbps 以上に達する場合にのみ必要です。
      • --client <server>: クライアントモードを有効にし、iperf3 サーバーを実行するサーバーの IP アドレスまたは名前を設定します。

4. iperf3 がテストを完了するまで待ちます。サーバーとクライアントの両方で統計が毎秒表示され、最後に概要が表示されます。たとえば、以下はクライアントに表示される概要です。

   [ 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

   この例では、平均ビットレートは 14.4 Gbps でした。

5. サーバー上では以下の設定になります。

   1. Ctrl+C を押して iperf3 サーバーを停止します。

   2. firewalld で TCP ポート 5201 を閉じます。

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

手順

1. 接続の遅延を決定します。たとえば、クライアントからサーバーに ping を実行して、平均ラウンドトリップ時間 (RTT) を測定します。

   # 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

   この例では、レイテンシーは 17 ミリ秒です。

2. 次の式を使用して、チューニングするトラフィックの帯域幅遅延積 (BDP) を計算します。

   connection speed in bytes * latency in seconds = BDP in bytes

   たとえば、レイテンシーが 17 ミリ秒の 10 Gbps 接続の BDP を計算するには、次のようにします。

   (10 * 1000 * 1000 * 1000 / 8) * 0.017 = 21,250,000 bytes

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

   net.ipv4.tcp_rmem = 4096 262144 42500000
   net.ipv4.tcp_wmem = 4096 262144 42500000

   値をバイト単位で指定します。環境に最適化された値を特定するには、以下の大体の目安を参考にしてください。

   • デフォルトのバッファーサイズ (2 番目の値): この値をわずかに増やすか、最大でも 524288 (512 KiB) に設定します。デフォルトのバッファーサイズが大きすぎると、バッファーのコラプシングが発生し、結果としてレイテンシーが急増する可能性があります。
   • 最大バッファーサイズ (3 番目の値): 多くの場合、BDP の 2 倍から 3 倍の値で十分です。

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

   # sysctl -p /etc/sysctl.d/10-tcp-socket-buffers.conf

5. net.ipv4.tcp_rmem または net.ipv4.tcp_wmem パラメーターの 2 番目の値を変更した場合は、新しい TCP バッファーサイズを使用するようにアプリケーションを再起動します。

   3 番目の値のみを変更した場合は、自動チューニングによってこれらの設定が動的に適用されるため、アプリケーションを再起動する必要はありません。

検証

1. オプション: iperf3 を使用して TCP スループットをテストします。

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

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

手順

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

      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

手順

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 バッファーサイズを使用するには、アプリケーションを再起動します。

手順

1. nstat ユーティリティーを使用して、TcpExtTCPRcvCollapsed カウンターと TcpExtRcvPruned カウンターをクエリーします。

   # nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned
   #kernel
   TcpExtRcvPruned            0         0.0
   TcpExtTCPRcvCollapsed      612859    0.0

2. しばらく待ってから、nstat コマンドを再実行します。

   # nstat -az TcpExtTCPRcvCollapsed TcpExtRcvPruned
   #kernel
   TcpExtRcvPruned            0         0.0
   TcpExtTCPRcvCollapsed      620358    0.0

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

5. ss -nt コマンドを、各実行の間に数秒の待ち時間を設けて複数回実行します。

   出力の Recv-Q 列に高い値が 1 件だけリストされている場合、アプリケーションは 2 つの受信操作の間にありました。ただし、lastrcv が継続的に増加する一方で、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
        ...

        PSR 列には、プロセスが現在割り当てられている CPU コアが表示されます。

     2. 同じコア上で実行されている他のプロセスを特定し、それらを他のコアに割り当てることを検討してください。

手順

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:*

   バックログ (Recv-Q) 内の現在の接続数がソケットバックログ (Send-Q) より大きい場合、リッスンバックログはまだ十分大きくないため、チューニングが必要です。

2. オプション: 現在の TCP リッスンバックログ制限を表示します。

   # sysctl net.core.somaxconn
   net.core.somaxconn = 4096

3. /etc/sysctl.d/10-socket-backlog-limit.conf ファイルを作成し、り大きなリッスンバックログ制限を設定します。

   net.core.somaxconn = 8192

   アプリケーションは net.core.somaxconn カーネルパラメーターで指定したよりも多くのリッスンバックログを要求することができますが、カーネルはこのパラメーターで設定した番号にアプリケーションを制限することに注意してください。

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

   # sysctl -p /etc/sysctl.d/10-socket-backlog-limit.conf

5. 新しいリッスンバックログ制限を使用するようにアプリケーションを再設定します。

   • アプリケーションが制限の config オプションを提供している場合は、それを更新します。たとえば、Apache HTTP サーバーには、このサービスのリッスンバックログ制限を設定するための ListenBacklog 設定オプションが用意されています。
   • 制限を設定できない場合は、アプリケーションを再コンパイルします。
   重要

   net.core.somaxconn カーネル設定とアプリケーションの設定の両方を常に更新する必要があります。

6. アプリケーションを再起動します。

検証

1. Systemd ジャーナルを監視して、possible SYN flooding on port <port_number> エラーメッセージがさらに発生していないかどうかを確認します。

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:*

   バックログ (Recv-Q) 内の現在の接続数がソケットバックログ (Send-Q) より大きい場合、リッスンバックログが十分に大きくないため、さらなるチューニングが必要です。

1. rhel-10-for-x86_64-baseos-debug-rpms リポジトリーを有効にします。

   # subscription-manager repos --enable rhel-10-for-x86_64-baseos-debug-rpms

2. kernel-debuginfo-common-x86_64 パッケージをインストールします。

   # dnf install kernel-debuginfo-common-x86_64

3. コード例が /usr/src/debug/kernel-<version>/linux-<version>/tools/testing/selftests/net/reuseport_bpf_cpu.c ファイルで利用できるようになります。

手順

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

   Pre-set maximums セクションにはキューの総数が表示され、Current hardware settings には受信キュー、送信キュー、その他のキュー、または結合されたキューに現在割り当てられているキューの数が表示されます。

2. オプション: 特定のチャネルにキューが必要な場合は、それに応じてキューを割り当てます。たとえば、4 つのキューを Combined チャネルに割り当てるには、次のように入力します。

   # ethtool -L enp1s0 combined 4

3. NIC がどの Non-Uniform Memory Access (NUMA) ノードに割り当てられているかを表示します。

   # cat /sys/class/net/enp1s0/device/numa_node
   0

   ファイルが見つからない場合、またはコマンドが -1 を返す場合は、ホストは NUMA システムではありません。

4. ホストが NUMA システムの場合は、どの CPU がどの NUMA ノードに割り当てられているかを表示します。

   # lscpu | grep NUMA
   NUMA node(s):       2
   NUMA node0 CPU(s):  0-3
   NUMA node1 CPU(s):  4-7

5. 上の例では、NIC には 4 つのキューがあり、NIC は NUMA ノード 0 に割り当てられています。このノードは CPU コア 0 - 3 を使用します。したがって、各送信キューを 0 - 3 の CPU コアの 1 つにマッピングします。

   # 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

   CPU コアと送信 (TX) キューの数が同じ場合は、TX キューで何らかの競合が発生するのを避けるために、1 対 1 マッピングを使用してください。複数の CPU を同じ TX キューにマップすると、各 CPU の送信操作によって TX キューのロック競合が発生し、送信スループットに悪影響が発生します。

   CPU のコア番号を含むビットマップをキューに渡す必要があることに注意してください。次のコマンドを使用してビットマップを計算します。

   # printf %x $((1 << <core_number> ))

検証

1. トラフィックを送信するサービスのプロセス ID (PID) を特定します。

   # pidof <process_name>
   12345 98765

2. XPS を使用するコアに PID を固定します。

   # numactl -C 0-3 12345 98765

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

   requeues カウンターが大幅な速度で増加しなくなると、TX キューロックの競合は発生しなくなります。

手順

1. オプション: NetworkManager 接続プロファイルを表示します。

   # nmcli connection show
   NAME     UUID                                  TYPE      DEVICE
   example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0

2. 接続プロファイルで GRO サポートを無効にします。

   # nmcli connection modify example ethtool.feature-gro off

3. 接続プロファイルを再度アクティベートします。

   # nmcli connection up example

検証

1. GRO が無効になっていることを確認します。

   # ethtool -k enp1s0 | grep generic-receive-offload
   generic-receive-offload: off

2. サーバー上のスループットを監視します。この設定がホスト上の他のアプリケーションにマイナスの影響を与える場合は、NetworkManager プロファイルで GRO を再度有効にします。

手順

1. ドライバーを特定します。

   # ethtool -i enp0s31f6
   driver: e1000e
   version: ...
   firmware-version: ...
   ...

   特定の機能には、特定のドライバーとファームウェアのバージョンが必要になる場合があることに注意してください。

2. カーネルモジュールの利用可能なパラメーターを表示します。

   # modinfo -p e1000e
   ...
   SmartPowerDownEnable:Enable PHY smart power down (array of int)
   parm:RxIntDelay:Receive Interrupt Delay (array of int)

   パラメーターの詳細は、カーネルモジュールのドキュメントを参照してください。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>

   たとえば、ポートの省電力メカニズムを有効にし、受信割り込みの生成を 4 ユニットに設定するには、次のように入力します。

   options e1000e SmartPowerDownEnable=1 RxIntDelay=4

4. モジュールをアンロードします。

   # modprobe -r e1000e

   警告

   アクティブなネットワークインターフェイスが使用するモジュールをアンロードすると、接続が即座に終了し、サーバーからロックアウトされる可能性があります。

5. モジュールをロードします。

   # modprobe e1000e

6. ネットワーク接続を再アクティブ化します。

   # nmcli connection up <profile_name>

検証

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

   すべてのモジュールがパラメーター設定をカーネルリングバッファーに記録するわけではないことに注意してください。

2. 特定のカーネルモジュールは、モジュールパラメーターごとに /sys/module/<driver>/parameters/ ディレクトリーにファイルを作成します。これらの各ファイルには、このパラメーターの現在の値が含まれています。これらのファイルを表示して設定を確認できます。

   # cat /sys/module/<driver_name>/parameters/<parameter_name>

手順

1. インターフェイスで利用可能なオフロード機能とその現在の状態を表示します。

   # ethtool -k enp1s0
   ...
   esp-hw-offload: on
   ntuple-filters: off
   rx-vlan-filter: off [fixed]
   ...

   出力はハードウェアとそのドライバーの機能によって異なります。[fixed] のフラグが付いている機能の状態は変更できないことに注意してください。

2. オフロード機能を一時的に無効にします。

   # ethtool -K <interface> <feature> <on|off>

   • たとえば、enp10s0u1 インターフェイスで IPsec Encapsulating Security Payload (ESP) オフロードを一時的に無効にするには、次のように入力します。

     # ethtool -K enp10s0u1 esp-hw-offload off

   • たとえば、enp10s0u1 インターフェイスで Receive Flow Steering (aRFS) フィルタリングを一時的に有効にするには、次のように入力します。

     # ethtool -K enp10s0u1 ntuple-filters on

検証

1. オフロード機能の状態を表示します。

   # ethtool -k enp1s0
   ...
   esp-hw-offload: off
   ntuple-filters: on
   ...

2. オフロード機能を変更する前に発生した問題がまだ存在するかどうかをテストします。

   • 特定のオフロード機能を変更した後に問題が解消された場合は、次のようにします。

     1. Red Hat サポート に連絡して問題を報告してください。
     2. 修正が利用可能になるまで、オフロード機能を永続的に設定すること を検討してください。

   • 特定のオフロード機能を無効にしても問題が解決しない場合は、以下を実行します。

     1. ethtool -K <interface> <feature> <on|off> コマンドを使用して、設定を前の状態にリセットします。
     2. 異なるオフロード機能を有効または無効にして、問題を絞り込みます。

手順

1. オフロード機能の状態を変更するネットワークインターフェイスを使用する接続プロファイルを特定します。

   # nmcli connection show
   NAME     UUID                                  TYPE      DEVICE
   Example  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0
   ...

2. オフロード機能の状態を永続的に変更します。

   # nmcli connection modify <connection_name> <feature> <on|off>

   • たとえば、Example 接続プロファイルで IPsec Encapsulating Security Payload (ESP) オフロードを永続的に無効にするには、次のように入力します。

     # nmcli connection modify Example ethtool.feature-esp-hw-offload off

   • たとえば、Example 接続プロファイルでアクセラレート Receive Flow Steering (aRFS) フィルタリングを永続的に有効にするには、次のように入力します。

     # nmcli connection modify Example ethtool.feature-ntuple on

3. 接続プロファイルを再度アクティベートします。

   # nmcli connection up Example

手順

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

   名前に drop、discard または error を含むパケットカウンターを特定します。これらの特定の統計は、ネットワークインターフェイスコントローラー (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

   • usecs 値は、受信機または送信機が割り込みを生成する前に待機するマイクロ秒数を指します。
   • frames 値は、受信機または送信機が割り込みを生成する前に待機するフレーム数を指します。

   • irq 値は、ネットワークインターフェイスがすでに割り込みを処理している場合に、割り込み調整を設定するために使用されます。

     注記

     すべてのネットワークインターフェイスカードが、出力例のすべての値のレポートと変更をサポートしているわけではありません。

   • Adaptive RX/TX 値は、割り込み結合設定を動的に調整する適応割り込み結合メカニズムを表します。Adaptive RX/TX が有効な場合、NIC ドライバーはパケット条件に基づいて、結合値を自動計算します (アルゴリズムは NIC ドライバーごとに異なります)。

4. 必要に応じて結合設定を変更します。以下に例を示します。

   • ethtool.coalesce-adaptive-rx が無効になっている間に、RX パケットの割り込みを生成するまでの遅延を 100 マイクロ秒に設定するように ethtool.coalesce-rx-usecs を設定します。

     # nmcli connection modify enp1s0 ethtool.coalesce-rx-usecs 100

   • ethtool.coalesce-rx-usecs がデフォルト値に設定されている間、ethtool.coalesce-adaptive-rx を有効にします。

     # nmcli connection modify enp1s0 ethtool.coalesce-adaptive-rx on

     Adaptive-RX 設定を次のように変更します。

     • 低遅延 (50 us 未満) を優先する場合は、Adaptive-RX を有効にしないでください。
     • スループットを優先する場合は、Adaptive-RX を有効にしてもおそらく問題はありません。適応割り込み結合メカニズムを使用しない場合は、ethtool.coalesce-rx-usecs に 100 us や 250 us などの大きな値を設定することをお試しください。
     • ご自身のニーズが明確でない場合は、問題が発生するまでこの設定を変更しないでください。

5. 接続を再度有効にします。

   # nmcli connection up enp1s0

手順

1. たとえば、RX オフロード機能を有効にし、enp1s0 接続プロファイルで TX オフロードを無効にするには、次のコマンドを実行します。

   # nmcli con modify enp1s0 ethtool.feature-rx on ethtool.feature-tx off

   このコマンドは、RX オフロードを明示的に有効にし、TX オフロードを無効にします。

   設定可能な設定のリストは、システムの nm-settings-nmcli(5) man ページの ethtool setting セクションを参照してください。

2. 以前に有効または無効にしたオフロード機能の設定を削除するには、機能のパラメーターを null 値に設定します。たとえば、TX オフロードの設定を削除するには、次のコマンドを実行します。

   # nmcli con modify enp1s0 ethtool.feature-tx ""

3. ネットワークプロファイルを再度アクティブにします。

   # nmcli connection up enp1s0

手順

1. 次の内容を含む Playbook ファイル (例: ~/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

   サンプル Playbook で指定されている設定は次のとおりです。

   gro: no

   Generic Receive Offload (GRO) を無効にします。

   gso: yes

   Generic Segmentation Offload (GSO) を有効にします。

   tx_sctp_segmentation: no

   TX Stream Control Transmission Protocol (SCTP) セグメンテーションを無効にします。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. たとえば、enp1s0 接続プロファイルで受信パケットの最大数を 128 に設定するには、次のコマンドを実行します。

   # nmcli connection modify enp1s0 ethtool.coalesce-rx-frames 128

   設定可能な設定のリストは、システムの nm-settings-nmcli(5) man ページの ethtool setting セクションを参照してください。

2. coalesce 設定を削除するには、null 値に設定します。たとえば、ethtool.coalesce-rx-frames 設定を削除するには、次のコマンドを実行します。

   # nmcli connection modify enp1s0 ethtool.coalesce-rx-frames ""

3. ネットワークプロファイルを再度アクティブにするには、以下を実行します。

   # nmcli connection up enp1s0

手順

1. 次の内容を含む Playbook ファイル (例: ~/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

   サンプル Playbook で指定されている設定は次のとおりです。

   rx_frames: <value>

   RX フレームの数を設定します。

   tx_frames: <value>

   TX フレームの数を設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. インターフェイスのパケットドロップ統計を表示します。

   # ethtool -S enp1s0
       ...
       rx_queue_0_drops: 97326
       rx_queue_1_drops: 63783
       ...

   コマンドの出力は、ネットワークカードとドライバーに依存することに注意してください。

   discard または drop カウンターの値が高い場合は、カーネルがパケットを処理できるよりも速く、使用可能なバッファーがいっぱいになることを示します。リングバッファーを増やすと、このような損失を回避できます。

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

   Pre-set maximums セクションの値が Current hardware settings セクションよりも高い場合は、次の手順で設定を変更できます。

3. このインターフェイスを使用する NetworkManager 接続プロファイルを特定します。

   # nmcli connection show
   NAME                UUID                                  TYPE      DEVICE
   Example-Connection  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0

4. 接続プロファイルを更新し、リングバッファーを増やします。

   • RX リングバッファーを増やすには、次のように実行します。

     # nmcli connection modify Example-Connection ethtool.ring-rx 4096

   • TX リングバッファーを増やすには、次のように実行します。

     # nmcli connection modify Example-Connection ethtool.ring-tx 4096

5. NetworkManager 接続をリロードします。

   # nmcli connection up Example-Connection

   重要

   NIC が使用するドライバーによっては、リングバッファーを変更すると、ネットワーク接続が短時間中断されることがあります。

手順

1. 次の内容を含む Playbook ファイル (例: ~/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

   サンプル Playbook で指定されている設定は次のとおりです。

   rx: <value>

   受信するリングバッファーエントリーの最大数を設定します。

   tx: <value>

   送信するリングバッファーエントリーの最大数を設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

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

2. ネットワークインターフェイスのチャネル設定を更新します。

   # nmcli connection modify enp1s0 ethtool.channels-rx 4 ethtool.channels-tx 3 ethtool.channels-other 9 ethtool.channels-combined 50

3. ネットワークプロファイルを再度アクティブにします。

   # nmcli connection up enp1s0

手順

1. レート制限を無効にするには、/etc/systemd/journald.conf ファイルを編集し、[Journal] セクションの RateLimitBurst パラメーターのコメントを解除し、その値を 0 に設定します。

   RateLimitBurst=0

2. systemd-journald サービスを再起動します。

   # systemctl restart systemd-journald

3. 以下の内容で /etc/NetworkManager/conf.d/95-nm-debug.conf ファイルを作成します。

   [logging]
   domains=ALL:TRACE

   domains パラメーターには、複数のコンマ区切りの domain:level ペアを含めることができます。

4. NetworkManager サービスを再起動します。

   # systemctl restart NetworkManager

手順

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

2. ログレベルおよびドメインを変更するには、以下のオプションを使用します。

   • すべてのドメインのログレベルを同じ LEVEL に設定するには、次のコマンドを実行します。

     # nmcli general logging level LEVEL domains ALL

   • 特定のドメインのレベルを変更するには、以下を入力します。

     # nmcli general logging level LEVEL domains DOMAINS

     このコマンドを使用してログレベルを更新すると、他のすべてのドメインのログが無効になることに注意してください。

   • 特定のドメインのレベルを変更し、他のすべてのドメインのレベルを保持するには、次のコマンドを実行します。

     # nmcli general logging level KEEP domains DOMAIN:LEVEL,DOMAIN:LEVEL