Linuxネットワーク性能パラメータ

 (github.com/leandromoreira)
4 ポイント 投稿者 GN⁺ 2023-09-07 | 1件のコメント | WhatsAppで共有
  • Linuxのネットワークフローの中でよく使われる sysctl/network パラメータ がどこに位置するのかを示す短いチュートリアル
  • あらゆる状況で高スループットと低レイテンシを同時に提供する cargo cult 値 は現実的ではなく、最新のカーネルバージョンではデフォルト値が適切に調整されており、デフォルト値の変更が性能を損なう可能性がある
  • 受信経路は、NICのMAC/FCS確認、DMA、受信 ring buffer、hard IRQ、NAPI、soft IRQ、ingress qdisc、netfilter、TCP状態マシン、tcp_rmem ベースの受信バッファ、アプリケーションの読み取りまでの流れとして整理されている
  • 送信経路は、アプリケーション sendmsg、skb_buff の割り当て、tcp_wmem ベースのソケット書き込みバッファ、TCP/IPヘッダ処理、netfilter、txqueuelen ベースの output qdisc、transmit ring buffer、DMA、NIC送信完了IRQまでの流れとして整理されている
  • 主要な調整項目は、バースト処理、CPU使用率、レイテンシ、ドロップの観察と結び付いている
    • rx, tx ring buffer は、接続バーストをドロップなしで受けるためのキューであり、増やすとレイテンシが増える可能性がある
    • rx-usecs, tx-usecs, rx-frames, tx-frames は、hard IRQ発生前の待機時間・フレーム数であり、CPU使用率とhard IRQを減らし、レイテンシを代償にスループットを高められる
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog は、NAPI polling cycle と ingress qdisc の処理量に関連する
    • txqueuelen と default_qdisc は、OUTPUT側のキューとデフォルトの queuing discipline に関連する
  • 確認・変更・監視は ethtool, sysctl, ip, tc, /proc ファイルを中心に構成されている
    • 例: ring buffer の確認 ethtool -g ethX、変更 ethtool -G ethX rx value tx value
    • 例: net.core.netdev_budget_usecs の確認 sysctl net.core.netdev_budget_usecs、変更 sysctl -w net.core.netdev_budget_usecs value
    • 例: default_qdisc の確認 sysctl net.core.default_qdisc、監視 tc -s qdisc ls dev ethX
  • TCPバッファ項目では tcp_rmem, tcp_wmem, tcp_moderate_rcvbuf を扱い、tcp_moderate_rcvbuf が設定されているとTCPが受信バッファサイズを自動調整しようと試みる
  • TCP状態と輻輳制御に関する項目として net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies, tcp_slow_start_after_idle もあわせて整理されている
  • Linux内部のネットワーク追跡は perf で確認でき、例のコマンドは perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null 形式
  • テストと監視ツールとして iperf3, vegeta, netdata, prometheus + grafana + node exporter full dashboard の組み合わせを提示している

関連記事

1件のコメント

 
GN⁺ 2023-09-07
Hacker Newsのコメント

  • Ubuntu Linuxのデフォルトでは net.ipv4.tcp_rmem が約6MB、net.core.rmem_max が約1MBなので、奇妙な状況が起きる
    デフォルトのTCPソケットは必要に応じてTCP受信ウィンドウが6MBまで上がるが、ユーザー空間アプリが setsockopt SO_RCVBUF を呼ぶと、すでに6MBが可能だったソケットも最大1MBに制限される
    6MBから4MBに減らそうとしても結果が1MBになる、といった具合で非常に奇妙に見え、SO_SNDBUF/wmem にも同じことが当てはまる
    Linuxがこれらのオプションの優先順位を混同しているように見えるが、なぜ core.rmem_max をもっと大きくして権威ある指示値として扱わないのか、歴史的な理由があるのか気になる

    • 過剰にバッファリングされたデータ量を制限したいのであれば、SO_SNDBUF/wmem の代わりに TCP_NOTSENT_LOWAT を下げられる
      この値は帯域幅遅延積（BDP）に必要な量を超えて追加でバッファリングされる量を制限する
    • net.ipv4.tcp_rmem の最大値は、カーネルが行う自動チューニングの上限である
      SO_RCVBUF を設定した瞬間、そのソケットでは自動チューニングが外れ、net.core.rmem_max が最大値になる
      Documentation/networking/ip-sysctl.rst にかなり明確に文書化されている

  • パケットが NIC に入ってからユーザー空間に到達するまでの全段階を示している点まで含めて素晴らしい
    ネットワーク性能に関連してもう一つ付け加えるなら、複数CPUがあるシステムでは、大型サーバーで一般的な NUMA割り当て を確認すべき
    ネットワークカードが片方のCPU側にあり、アプリケーションが別のCPUで動いていると、性能にも影響し得る

  • Linuxのデフォルト輻輳制御である net.ipv4.tcp_congestion_control を bbr に変えるだけでも、状況によっては非常に大きな差が出る
    おそらく距離、断続的なパケットロスとジッター、カプセル化がある場合に特にそうらしい
    この1年ほど、client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host という流れの問題をデバッグしていたが、平均すると理論上の最大スループットの20%を超えるのが難しく、接続も時間がたつとほとんど止まったように遅くなった
    接続を頻繁に強制的に閉じるという応急処置をしていたが、輻輳制御を bbr に変えると理論上の最大に近いスループットと安定した接続が得られ、この変更はWireguardの両側に必要だった

    • BBR は、損失を輻輳シグナルとして使わない点が異なる
      ほとんどのTCPスタックは最初に損失が見えると送信ウィンドウを半分にするか大きく下げるため、損失のあるVPNだったり、10Mb/sのVPNアップリンクに1Gb/sで大きなバーストを送ったりすると、TCPは損失を見て大きく後退する
      BBRはボトルネック帯域幅を見つけようとし、往復時間を測定してRTTが増加するまで送信レートを上げる
      RTTが増加すると、経路で最も狭い区間にキューがたまっていると仮定し、キューがはけてRTTが正常化するまで送信レートを下げ、その速度でしばらく送った後、また少し上げてみる
      数年前、10Mb/sのケーブル上り回線から1Gb/s対称の光回線に替えたのに会社VPNへのアップロードが5Mb/s程度にとどまって苛立っていたが、FreeBSDで RACK TCP またはBBRに変えると、VPNの上限である約40Mb/sまで約8倍に上がった
    • BBRv1 は壊れているので、公開インターネットでは使うべきではない
      魔法のような値を1つ設定すれば良くなる、というコピペ式カーゴカルトな性能チューニングは、原文が言おうとしていることと正反対である
      幸いGoogleがBBRv3をアップストリームしているので、近いうちに改善するはずだ
    • 輻輳制御は、データを送る側から受ける側への方向で動作する
      一方向の性能だけを改善したいのであれば、Wireguardの両側を両方とも変える必要はない
      BBRv1については他のコメントに同意するし、Linuxカーネルの cubic実装 はほとんどのアプリケーションでかなりうまく動作する

  • Wi-Fiアダプターにも性能チューニングが意味を持つのか気になる
    デスクトップでは、機能をオフにする以外に i210 と i225 のイーサネット問題を直す方法があるのかも気になる
    最近いちばん一般的な NIC はこの2つのように思えるのに、一般的なネットワークハードウェアとドライバーがなぜここまで欠陥だらけなのかよく分からない
    RISC-V には大いに関心があるが、完全に公開された正しい NIC から始めてみてはどうかと思う
    i210 より安ければ最終的には採用されるだろうが、もしかすると不可能なことかもしれない

    • 最大ローカルネットワークスループットの 10〜20% を犠牲にできるなら、Wi-Fi の公平性を大きく高め、ping 時間を改善し、バッファブロートを減らせる
      ただし Wi-Fi ではランダムな ping の急増は依然として発生する
      https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... には、AQM の有効化とチューニング、スループットとレイテンシのトレードオフを扱う大きなスレッドがある
    • i225 は単に壊れた代物だが、i210 では優れた性能が出る
      同時代の CPU にとって 1Gb はさほど難しい水準でもなく、i210 はキューを4つ提供する
      i210 の何が不満なのか気になる
    • i225 オンボード搭載のマザーボードを使っていたが、PCIe I350 を買って問題を解決した

  • 図で整理された Linux ネットワークキューの概要がすばらしく、どこか壁に貼っておきたいほどだ
    Brendan の『Systems Performance』も Linux ネットワーク性能などをよく扱っており、すでに第2版まで出ている
    どちらの版も優れているが、第2版は主に Linux に集中し、第1版は Solaris も含んでいる
    より最近では、同じ著者による『BPF Performance Tools』もある
    [1] Systems Performance: Enterprise and the Cloud, 2nd Edition (2020)
    https://www.brendangregg.com/systems-performance-2nd-edition...
    [2] BPF Performance Tools:
    https://www.brendangregg.com/bpf-performance-tools-book.html

  • 記事をざっと読むだけでも楽しく、調査と構成がとても良かった
    ただ、Linux ネットワークパラメーターを定期的にチューニングしている人が実際には誰なのか気になる

  • この文書はどこかに TCP だと明記すべきだと思う
    内容は TCP 関連の関心事に非常に集中しており、人々は主に TCP を使うので有用ではある
    しかしデフォルトの UDP チューニング値はひどく低いのに、その部分が目立って抜けている

    • UDP チューニングに良い資料があるのか気になる

  • 似た内容を扱う動画やシリーズをおすすめしてほしい
    一般的なネットワーキング資料は多いが、Linux の具体的な実装を扱う資料は見つけにくかった

    • マイクロコントローラーの観点でも同じような資料が必要だ
      簡単な TCP エコーサーバーをマイクロコントローラー向けに作ってみたいが、ほとんどの例はベンダー独自の TCP ライブラリを使うだけで、ルーターに直接接続を設定して確立する過程をほとんど説明していない