Linuxで10Gbファイバー接続のパフォーマンスを微調整する方法TCPパフォーマンス
お客様のスピードテスト専用の2台のRed Hatサーバーがあります。どちらも10Gbファイバー接続を使用し、10Gbリンク上にあります。これらのサーバー間のすべてのネットワーク機器は10Gb/sを完全にサポートしています。 IperfまたはIperf3を使用すると、約6.67Gb/sが得られます。とはいえ、1台のサーバーが稼働中で（顧客がヒットしている）、もう1台のサーバーはオンラインですが、使用されていません。 （ATMのテストに使用しています）6.67Gb/sも1つの方法です。これらをサーバーAとサーバーBと呼びます。
サーバーAがiperfサーバーとして機能する場合、6.67Gb/sの速度が得られます。サーバーAがサーバーBのクライアントとして機能する場合、約20Mb/sしかプッシュできません。
私がやった事：
これまでのところ、私が行った唯一のことは、両方のサーバーのTX/RXバッファーを最大に増やすことです。 1つは512に設定され、もう1つは453に設定されました。（RXのみ、TXはすでに最大になっています）したがって、更新後の両方で次のようになります。
Server A:
Ring parameters for em1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Server B:
Ring parameters for p1p1:
Pre-set maximums:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
Current hardware settings:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
NICSは次のようになります。
Server A:
ixgbe 0000:01:00.0: em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
Serer B:
bnx2x 0000:05:00.0: p1p1: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
Server A ethtool stats:
rx_errors: 0
tx_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_csum_offload_errors: 123049
Server B ethtool stats:
[0]: rx_phy_ip_err_discards: 0
[0]: rx_csum_offload_errors: 0
[1]: rx_phy_ip_err_discards: 0
[1]: rx_csum_offload_errors: 0
[2]: rx_phy_ip_err_discards: 0
[2]: rx_csum_offload_errors: 0
[3]: rx_phy_ip_err_discards: 0
[3]: rx_csum_offload_errors: 0
[4]: rx_phy_ip_err_discards: 0
[4]: rx_csum_offload_errors: 0
[5]: rx_phy_ip_err_discards: 0
[5]: rx_csum_offload_errors: 0
[6]: rx_phy_ip_err_discards: 0
[6]: rx_csum_offload_errors: 0
[7]: rx_phy_ip_err_discards: 0
[7]: rx_csum_offload_errors: 0
rx_error_bytes: 0
rx_crc_errors: 0
rx_align_errors: 0
rx_phy_ip_err_discards: 0
rx_csum_offload_errors: 0
tx_error_bytes: 0
tx_mac_errors: 0
tx_carrier_errors: 0
tx_deferred: 0
recoverable_errors: 0
unrecoverable_errors: 0
潜在的な問題：サーバーAに大量のrx_csum_offload_errorsがあります。サーバーAは運用環境にあるサーバーであり、CPU割り込みがここでの根本的な要因であり、何がエラーを表示しているのかを考えざるを得ません。
サーバーAからのcat/proc/interrupts：
122: 54938283 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1- TxRx-0
123: 51653771 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-1
124: 52277181 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-2
125: 51823314 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-3
126: 57975011 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-4
127: 52333500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-5
128: 51899210 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-6
129: 61106425 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-7
130: 51774758 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-8
131: 52476407 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-9
132: 53331215 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-Edge em1-TxRx-10
133: 52135886 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
これが問題である可能性がある場合、rx-checksummingのヘルプを無効にすることはできますか？また、NICはCPU時間を必要としないため、本番環境にないサーバーにはCPU割り込みがありません。これは理にかなっています。
Server A:
ethtool -k em1
Features for em1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-unneeded: off
tx-checksum-ip-generic: off
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: on [fixed]
tx-checksum-sctp: on [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
loopback: off [fixed]
私たちのネットワークギアがフレームをサポートしていないため不可能であるジャンボフレームを使用する以外に、10Gbネットワークに最適なTCPパフォーマンスを提供するために他に何ができるか、または確認できますか？ 6.67Gb/sではないthat悪いサーバーの1つが稼働中であり、CPUに関する私の仮説がNICを生成していることを考慮しています。しかし、 10Gbリンクでの20Mb/sの反対方向の速度は、まったく受け入れられません。
サーバーAの仕様：x64 24v CPU 32GB RAM RHEL 6.7
サーバーB仕様：x64 16v CPU 16GB ram RHEL 6.7
Linux/Intelでは、パフォーマンス分析に次の方法を使用します。
ハードウェア：
turbostat
コア、周波数、SMIの数のC/P状態を探します。 [1]cpufreq-info
現在のドライバー、周波数、ガバナーを探します。atop
コア全体の割り込み分散を探します
コンテキストスイッチ、割り込みを探します。ethtool
-S-統計、エラー、ドロップ、オーバーラン、見逃された割り込みなどを探します
-kオフロード用、GRO/GSOを有効化、rss（/ rps/rfs）/ xps
-gリングサイズ、増加
-c割り込み合体
カーネル：
/proc/net/softirq[2]および/proc/interrupts[3]
再び、配布、見逃した、遅延した割り込み、（オプション）NUMAアフィニティperf top
カーネル/ベンチマークが時間を費やしている場所を探します。iptables
パフォーマンスに影響を与える可能性のあるルール（ある場合）があるかどうかを確認します。netstat -s、netstat -m、/proc/net/*
エラーカウンターとバッファーカウントを探す- sysctl/grub
ここで調整することはたくさんあります。ハッシュテーブルのサイズを増やして、メモリバッファ、輻輳制御、およびその他のノブで遊んでみてください。
あなたの場合、あなたの主な問題はコア全体の割り込みの分散ですので、それを修正することはあなたの最善の行動です。
PS。これらの種類のベンチマークでは、カーネルとドライバー/ファームウェアのバージョンが重要な役割を果たすことを忘れないでください。
PPS。おそらくIntel [4]の最新のixgbeドライバをインストールしたいと思うでしょう。 READMEを読んでスクリプトディレクトリを確認することを忘れないでください。パフォーマンスに関するヒントがたくさんあります。
[0] Intelには、ネットワークパフォーマンスのスケーリングに関する素晴らしいドキュメントもあります。
https://www.kernel.org/doc/Documentation/networking/scaling.txt
[1]プロセッサーを特定のC状態に固定できます。
https://Gist.github.com/SaveTheRbtz/f5e8d1ca7b55b6a7897b
[2]次の方法でデータを分析できます。
https://Gist.github.com/SaveTheRbtz/172b2e2eb3cbd96b598d
[3]次のアフィニティを設定できます。
https://Gist.github.com/SaveTheRbtz/8875474
[4] https://sourceforge.net/projects/e1000/files/ixgbe%20stable/
サーバーは同じ仕様（メーカーとモデル）ですか？ sysctl.confを変更しましたか？
割り込みはCPU0でのみ発生するため、irqbalanceを有効にする必要があります。
EL6で調整されたプロファイルを使用していない場合は、スケジュール here に従って、ワークロードに近いプロファイルを選択する必要があります。
LRO（Large Receive Offload）を無効にしてみます...オンになっているものとオフになっているものがあると思います。
これはNIC /ドライバに依存しますが、一般的に、私たちの環境でそれを見ると、1つ見逃していたことがわかり、LROを無効にします
単一のCPUコアに制限されているため、iperfのインスタンスを1つだけ実行する場合は、速度6 Gb/sで問題ありません。 2つのプロセスを同時に実行すると、予想される10Gb/sが得られます。
一方向で20Mb/sの問題は、ドライバー/ファームウェア/ハードウェアの非互換性の問題のようです。
次のトラブルシューティング手順を試すことをお勧めします。
NICにはデュアルポートがあるため、最初に両方のNICでループバック速度テストを試します。サーバーAまたはサーバーBで問題を特定するのに役立ちます。2.パッチコードを変更します。 3.新しいドライバーを試します。 4.ファームウェアをアップグレードします。 5. NICを変更する）