WANリンクのパフォーマンステストの方法論

11

約200マイル離れた場所間に、新しく多様にルーティングされた1 Gbpsイーサネットリンクのペアがあります。「クライアント」は新しい適度に強力なマシン（HP DL380 G6、デュアルE56xx Xeons、48GB DDR3、300GB 10krpm SASディスクのR1ペア、W2K8R2-x64）であり、「サーバー」もまともなマシンです（HP BL460c G6 、デュアルE55xx Xeon、72GB、146GB 10krpm SASディスクのR1ペア、デュアルCisco MDS9509にリンクされたデュアルポートEmulex 4Gbps FC HBA、次に128 x 450GB 15krpm FCディスクを備えた専用HP EVA 8400、RHEL 5.3-x64）。

クライアントからSFTPを使用すると、大きな（> 2GB）ファイルを使用した場合のスループットは約40Kbpsしかありません。サーバーから「他のローカルサーバー」テストを実行し、ローカルスイッチ（Cat 6509）で約500 Mbpsを確認しました。クライアント側でも同じことを行いますが、それは1日かそこらです。

問題がリンクプロバイダーにあることをリンクプロバイダーに証明するために、他にどのテスト方法を使用しますか？

networking performance sftp

— チョッパー3
ソース

これに対する答えも知りたいです。私たちは私たちの100Mbitの専用線は、来週のいつか:)インストールします

— トム・オコナー

ユーザー37899が言うように-結果は高く評価されるでしょう。

— pQd

アップデートはありますか？これがどうなるか興味があります。

— カイルブラント

リンクプロバイダーを「かなりひどく」打ち負かしました（皮肉なことに、彼らは私が働いている同じ組織の一部です！）-彼らはまだ私たちに戻ってきていません。

— -Chopper3

1

ああ、ところで、もしなぜ私がserverfault.com/questions/134467/に 7票を獲得し、このために1 票を得るのかを理解できれば、私は知りたいです;

— カイルブラント

10

象のチューニング：
これにはチューニングが必要な場合がありますが、おそらくpQdが言うように、ここでは問題になりません。この種のリンクは、「ロング、ファットパイプ」またはゾウ（RFC 1072を参照）として知られています。これは距離を移動する太いギガビットパイプであるため（距離は実際には時間/レイテンシです）、tcp受信ウィンドウは大きくする必要があります（図については、TCP / IP Illustrated Volume 1、TCP Extensionsセクションを参照してください）。

受信ウィンドウの必要性を把握するには、帯域幅遅延積を計算します。

Bandwidth * Delay = Product

10MSの遅延がある場合、この計算では約1.2 MBの受信ウィンドウが必要であると推定されます。上記の式で計算を自分で行うことができます。

echo $(( (1000000.00/.01)/8  )) 
12500000

したがって、パケットダンプを実行して、tcpウィンドウスケーリング（より大きなウィンドウを許可するTCP拡張）が発生しているかどうかを確認して、大きな問題が何であれ、これを調整することができます。

ウィンドウバウンド：
これが問題であり、スケーリングなしのウィンドウサイズバウンドである場合、ウィンドウスケーリングが設定されておらず、パイプサイズに関係なく約200ミリ秒のレイテンシがある場合、次の結果が期待されます。

Throughput = Recieve Window/Round Trip Time

そう：

echo $(( 65536/.2 ))
327680 #Bytes/second

表示されている結果を得るには、遅延を解決するだけでよく、次のようになります。

RTT = RWIN/Throughput

（40 kBytes / sの場合）：

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

（私の数学を確認してください、そしてもちろんこれらはすべてのプロトコル/ヘッダーのオーバーヘッドを含んでいません）

— カイル・ブラント
ソース

先週の担当者の一時的な「追い越し」に対して少し罪悪感を覚えたことはご存知でしょう。その理由は、あなたの答えがどれほど良いか、そしてブームだからです！1.5 MBのMac Calculator.appではなく、シェルを使用して計算を行うことさえできます。：）ありがとうございました。

— Chopper3

1

あなたにも良い答えがあり、私は担当者に近い人がいるのが好きで、ゲームを少し強化します:-)クイックGoogleクエリは、あなたが私の質問にも答えていることを思い出させます：serverfault.com/questions/107263/ …。このコミュニティを「幸福」にしようとしているアクティブユーザーに本当に感謝しています。しかし、補完してくれてありがとう！

— カイルブラント

私も、もちろんチーズ以外に、自分自身がイライラする問題を抱えていると感じた人を助けたことを知っていることほど好きではありません。それは、私たちが不格好な質問をするときも嫌いだと言っていましたが、SOポッドキャスト82で私の質問を聞いたのですか？無料のSF Tシャツも手に入れました！

— Chopper3

私はほとんどのポッドキャストを聴いていますが、それを見逃していました。戻ってチェックアウトするでしょう（おそらく今週末）。

— カイルブラント

そのpQdについてすみません、私は実際にPDQバッハのようにPDQとしてあなたのニックネームを常に読んでいます：en.wikipedia.org/wiki/P._D._Q._Bach :-)

— カイルブラント

6

40kbpsは非常に低い[メディアコンバーター/デュプレックスの不一致が疑われるところまで[ただし、ギガビットがあるので半二重の場所がない！]など）。パケット損失または非常に高いジッターが関係する必要があります。

iperfは、利用可能なスループットを測定する最初のツールです。片側で走る

iperf -s

そしてもう一方に：

iperf -t 60 -c 10.11.12.13

次に、クライアント/サーバーの役割を交換し、二重化などに-dを使用します。テストを開始する前に両方のマシン間でmtrを実行し、未使用リンクの遅延/パケット損失を確認し、データ転送中にそれらがどのように変化するかを確認します。

ご覧ください。ジッタが非常に小さく、リンクが容量の90パーセントに飽和するまでパケット損失がありません。

* nixとwinの iperfについては、こちらとこちらをご覧ください。

* nixおよびwinの mtr 。

— pQd
ソース

リンクは6つの1000-base-zxリンクで構成されているため、その繰り返しによって遅延が生じる可能性がありますが、それでもあなたがどれほど低いかには驚かされます。方法、私はそれが存在したことを完全に忘れていた！

— Chopper3

結果を投稿してください！

— Unixの管理者

1

tracepathは、2つのサイト間のルーティングの問題を表示できます。

iperf、ttcp、およびbwpingは、有用な情報を提供します。

この1GBリンクがどのようにプロビジョニングされているか知っていますか？このリンクを介してブリッジングまたはルーティングしていますか？リンクのSLAは何ですか？あなたはあなたのリンクプロバイダーによって形作られることができましたか？

40kbsしか得られない場合、深刻な問題があります。1GB/ sリンクではなく1MBのリンクではないことを確認してください。あなたはおそらくリンクの速度があなたがそれを思っているものではないことに気付くでしょう:-)

— Unix用務員
ソース

あなたの答えをありがとう、それは専用のマルチセグメントブリッジドシングルモードファイバーリンクであり、L2だけであるため、シェイピングはまったく関係ありません。 :)

— Chopper3

1

LANへのブリッジング、つまりどこにもルーティングしない場合、ネットワークブロードキャストはリンク容量を浪費します。1GBの場合はわずかですが、ネットワークサービスの誤動作によりリンクが平坦化される可能性があります。私はこれらの橋があなたのコントロールの外にあると思います。これらのスイッチは過負荷になっているか、非常に高い遅延が発生している可能性があります。待ち時間が長いと、帯域幅が狭くなります。

— Unix Janitor

@ user37899-高いレイテンシーは低い帯域幅を意味する必要はありませんが、チューニングが必要です...とにかく-200マイルでどれだけのレイテンシーを得ることができるか-問題がなければ3-10ms以内ギガビットリンクでのarp [またはその他]ブロードキャストは、おそらく利用可能な容量全体のごく一部です。

— -pQd

1

リンクのパフォーマンスに影響を与えるようなレベルでネットワークブロードキャストが発生している場合、この新しいラインが登場するずっと前から内部パフォーマンスの問題が発生していることに気づいたと思います。

— -joeqwerty

@pQd私は実際に放送の嵐について話していました。

— Unix Janitor

0

RFC 2544またはY.156sam

これらは、キャリアによってSLAを証明するために行われるネットワークテストです。IPERFなどは、検証可能なネットワークテスト方法ではありません。

— アンセル・ガディ
ソース