iSCSI / NFSのパフォーマンスが非常に低い場合のトラブルシューティング戦略

3つのWindows 2008 R2ボックスにiSCSIターゲットを提供し、1つのOpenBSD 5.0ボックスにNFSを提供する新しいSynology RS3412RPxsがあります。

sshでRS3412にログインし、ddとさまざまなブロックサイズを使用して小さなファイルと6GBファイルの両方を読み書きすると、優れたディスクI / Oパフォーマンスが示されます。

iSCSI / NFSクライアントでddまたはiometerを使用すると、最大20Mbpsに到達します（これはタイプミスではありません。20Mbps）。Synologyの複数のGbit NICをより有効に活用したいと思っていました。

スイッチとNICポートの設定が自動ネゴシエートではなくギガビットに設定されていることを確認しました。ジャンボフレームを使用した場合と使用しない場合で違いはありません。pingでMTUが現在9000であることを確認しました。2つのファームウェアアップグレードが展開されています。

スイッチの問題を除外するために、iSCSIターゲットとイニシエーター間の直接リンクを試しますが、他のオプションは何ですか？

私はwireshark / tcpdumpを壊した場合、何を探しますか？

ここで共通のテーマのようですが、スイッチのフロー制御設定をもう一度見てください。スイッチにイーサネットカウンター統計がある場合は、それらを調べて、多数のイーサネットPAUSEフレームがあるかどうかを確認します。もしそうなら、それはおそらくあなたの問題です。一般に、スイッチでQOSを無効にすると、この問題が解決します。

そのようなフローは、さまざまなTCPフロー制御メソッドが正しく機能していないことを示唆しています。LinuxカーネルがVista以降のWindowsバージョンと通信するときにいくつかの問題が発生し、そのようなスループットが得られます。一見するとWiresharkによく表示される傾向があります。

絶対に最悪の可能性は、TCP遅延ackが完全に壊れており、次のようなトラフィックパターンが表示されることです。

packet
packet
[ack]
packet
packet
[ack]

NICドライバーの更新をWindowsサーバーに適用することで、この問題を解決しました。一部の（ブロードコム）サーバーに付属するスマートNICは、興味深い方法で失敗することがありますが、これはその1つです。

通常のトラフィックパターンは、大量のパケットとそれに続くAckパケットです。

もう1つ注意すべき点は、長い遅延です。疑わしい値は.2秒と1.0秒です。これは、一方の側が期待したものを取得しておらず、応答する前にタイムアウトになるまで待機していることを示しています。上記の不良パケットパターンとACKの200ミリ秒の遅延を組み合わせると、なんと1MB /秒のスループットが得られます。

これらは、気づきやすい悪いトラフィックパターンです。

私はその種のNASデバイスで作業したことがないので、見つかったものを修正することがいかに微調整できるかわかりません。