☰

LANの目標ネットワーク速度

tag-icon • tag-icon linux networking solaris zfs file-transfer
LANの目標ネットワーク速度

LAN上の異なるシステムに複数のNFSをエクスポートするSolaris 11システムがあります。テストのためにLinuxシステムをクライアントとして使用します。

読み取り速度をテストするための高速スクリプトを作成しましたが、ギガビットLANの平均読み取り速度は約110 Mbps（または13 MB / s）でした。もっと早くなると思ったと思います。 SSH（scp）は3.8 MB / sのみを提供しますが、これは暗号化されています。

httpはNFS比に似た11.5M/sを提供します。これはあまりにも低いですか？

この数のボトルネックは何ですか？

答え1

クライアントが転送を続けるため、NFSは実際にスループットを最大化できません。私に送ってくださいあまりにもデータサーバーへ（あまりにも数キロバイトに制限されています）さらに質問する前に、完全な回答をお待ちください。死んだすべてのキューが空のとき。ネットワーク内のすべてのFS（CIFS、SSHFS）には同じ種類の問題があります（そしてIIRC scp、またはたぶんsftp覚えていません）。

暗号化オーバーヘッドに加えて、いくつかの追加のsshパフォーマンス制限があります（参照：ここ詳細はこちら）。

チャンク要求を実行するクライアントを使用しない限り、HTTPはTCPである必要があるため、この制限はありません。 TCPは、輻輳を回避しながらスループットを最大化するために輻輳制御アルゴリズムを使用する必要があります。数キロバイトの初期転送は遅くなりますが、両方のコンピュータが同じスイッチを介して接続されている場合は、数十分の1秒以内に帯域幅を最大化できます。ネットワーク品質が悪い場合（例：奇妙なパケット損失）がある可能性があります。

試してみるべきこと：

  • /dev/zeroFSアクセスのボトルネックを排除するには、通常のTCP接続（socatまたはたとえば）を介してコンテンツを転送します。nc
  • ネットワークインターフェイス統計で、トランスポートエラーとTCPスタック統計を確認します（netstat -s）。
  • （TCPおよびUDP）を使用してiperfテストされました。

答え2

過去にも同様の状況が発生していましたが、解決策はSolarisとLinuxでv4の代わりにNFS v3を強制的にマウントすることでした。

Solaris 側では、/etc/default/nfs を編集し、サーバー側変数を server に設定し、NFS v3 側のみを許可できます。

変数名は覚えていませんが、説明が必要です。

実行中のテストが1つの大容量ファイルをコピーしていますか、または複数のファイルをコピーしていますか？複数のファイルで驚くことはありませんが、単一のファイルであれば良いと思います。

また、どのような基本的なストレージがありますか？シングルプレート？レイド設定？これはあなたのパフォーマンスにも影響します。

答え3

基本ファイルシステムはどのくらいのデータを提供しますか？ NFS自体は、見えるよりも速くデータを移動し、これは他のボトルネックがあることを示しています。 iperfを使用してネットワークがより高い帯域幅を配信できることを確認すると、これを確認できます。

Solarisシステムにログインし、ストリーミングがどれだけ速いかを確認するために、/dev/nullにエクスポートするファイルシステムのファイルをコピーします。すでにファイルシステムキャッシュにあるファイルに対してこの読み取りテストを実行したくない場合は、少しの労力が必要です。他のファイルシステムでは、マウント解除/マウントしてキャッシュを無効にすることができますが、ZFSではこれだけでは不十分です。

答え4

スタックの各部分の機能を理解する必要があります。 NFS共有ファイルシステムはどのような種類のディスクで構成されていますか？ SAS？ SATA？ SSD？種類とサイズ、RPMはどうなりますか？スピン遅延？ 4kハードですか？ ZFSは512バイトドライブ用に最適化されており、新しい「高度なフォーマット」ディスクには既知のパフォーマンスの問題があります。

I/Oワークロードはどれくらい大きいですか？これはリポジトリの表示速度にも影響します。

純粋なストレージの観点から、これらの問題はバックエンドディスクへのデータの書き込みと読み出し速度に影響を与えます。たとえば、NFS 共有が 7200RPM 1TB SATA ディスク上のファイルシステムにあり、ワークロードサイズが 64 KB で、ほとんどランダムであるとします。

Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time:        8.4 ms
Average Write Seek Time:       8.9 ms
Rotational latency:           .120 ms
Average Latency:             4.166 ms
Average Read Service Time:  12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs:           79.000
Best Case Write IOPs:          76.000
--------------------------------------------------------------------------------
Best Case Read Throughput:  4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs:         55.300
Real World Write IOPs:        53.200
--------------------------------------------------------------------------------
Real World Read Throughput:  3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------

これにより、特定のワークロードサイズで単一のディスクから得られる実際のパフォーマンスに関するアイデアを得ることができます。

次のI / Oが開始される前に書き込み承認が必要ないように書き込みキャッシュを使用するか、NFSファイルシステムを非同期でマウントすると、パフォーマンスが向上します。これはデータを危険にさらすので推奨されません。

バックエンドストレージのパフォーマンスを理解したら、NFS（v3？v4？tcp？udp？）またはSSH（どの暗号化アルゴリズムを使用していますか？より軽いアルゴリズムを使用できます）で作成されたストレージを見始めることができます。間接費。パフォーマンスを向上させるためのarcfourなどのアルゴリズム）またはネットワーク自体。安い1GbE NICはありますか？または、より高いエンドサーバー品質のネットワークカードを使用しますか？複数のサービス間でネットワークカードを共有していますか？ネットワークにトラフィックを生成する他のものはありますか？ネットワーク輻輳、衝突、または高い再送速度はどうですか？

これはバックエンドストレージの明らかなパフォーマンスをさらに低下させ、クライアントが非常に遅いように見えることを意味します。

さて、上記の数字は最悪のシナリオですか？ワークロードの100％ランダム同期。順次ワークロードがある場合、またはIOワークロードのサイズを増やすことができる場合は、パフォーマンスを大幅に向上させることができます。たとえば、IOサイズを128kに増やすことができる場合、パフォーマンスは2倍になり、NFSクライアントに応じてrsizeとwsizeをさまざまな設定に設定してパフォーマンスをテストできます。結局、収益が減少するポイントがあります。

複数のディスク、ミラー、またはRAIDがある場合は、その数を調整する必要があります。

実際のディスクパフォ​​ーマンスは、ディスクボックスの側面に印刷されたパフォーマンスとほとんど一致しません。

関連情報