web-dev-qa-db-ja.com

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ポート構成がギガビットに設定され、自動ネゴシエーションではない現在9000。2つのファームウェアアップグレードが展開されています。

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

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

performancenfsiscsitroubleshooting
9
Alex Holst

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

4
joeqwerty

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

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

packet
packet
[ack]
packet
packet
[ack]

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

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

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

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

私はその種類のNASデバイスで作業したことがないので、見つかったものを修正することがどれほど調整可能かわからない。

3
sysadmin1138