iSCSIネットワークでジャンボパケットを無効にする必要がありますか？
メインのデータベースエンジンを格納するSQLServer2000ボックスがあるとします。
ISCSI SANを追加しました。これで、サーバーには通常のネットワークに接続された1枚のカードとiSCSIネットワークに接続された1枚のカードがあります。
データは、アプリケーションサーバーであり、iSCSIネットワーク上にない別のサーバーを介して要求されます。
データサーバーのiSCSI接続（およびiSCSIネットワーク上の他のアイテム）でジャンボパケットを9000に有効にしました。
article by Jonathan Kehayiasを読んだ後、私たちがしたことが正しいかどうか疑問に思います。
私のOLTPシステムでこれをテストする最良の方法は何ですか？OSはWindows Server 2003 R2 Enterprise x64 SP2で、SQLServerはEnterprise2000x86です。
おそらくそれをテストする最も簡単な方法はSQLIOを使用することです。ここにチュートリアルがあります：
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
ジャンボフレームが役に立ったかどうかを確認するために、前後にテストすることができます。
リンク先の記事のアドバイスは非常に優れており、ジャンボフレームが汎用LAN環境で必ずしも良いアイデアではない理由を説明していますが、iSCSIネットワークトラフィック自体の性質については実際には説明しておらず、通常はメリットがあります。ディスクとしてのジャンボフレームからIOトラフィックは比較的大きなブロックになります（変更していない場合は8kb）。一部のSQL専門家はこれについて私を訂正したいと思うかもしれませんが、すべてのデータベースIOは8kbのチャンクになると思います。読み取り/書き込みブロックサイズが8kの場合、6つの標準サイズに分割する必要はなく、単一のIOを単一のジャンボフレームに収めることができます（プロトコルのオーバーヘッドは比較的低く、一般に100バイト未満です）。 。
スループットに大きな変化は見られないかもしれませんが（おそらく数％）、NICは通常6分の1の数値しか処理しないため、ネットワークインターフェイスドライバーからのCPU負荷と割り込み率が大幅に低下すると予想されます。同じ量のデータを運ぶパケットの。これはあなたにとって大きな問題ではないかもしれませんが、iSCSIトラフィックを伝送する複数のNICがある場合、CPUリソースのかなりのチャンクまたはビジーなサーバーになる可能性があります。 iSCSI\TCPオフロードを備えたスマートNICを使用している場合、メリットは明らかに低くなりますが、全体的にフレームサイズを大きくすると、iSCSIネットワークファブリック上のすべてのものが簡単になるため、引き続き推奨されます。
そうは言っても、可能であれば、いくつかのパフォーマンステストを実行するというBrentOzarの推奨を反映します。
助け以外の何かがあったら、私は驚きます。確かに、私はUnix SAであり、DBA/Networking/Windowsの担当者ではありませんが、それが何もしないことを期待しています（もちろん、エンドツーエンドでサポートされていると仮定します）。
DBは一度に少なくとも1ページを読み書きすることになると思います。通常、DBページはOSページと同じサイズです（ほとんどのRISCシステムは32ビットで4K、64ビットで8Kでしたが、 64ビットAMD64システムではまだ4Kだと思います）。確かに、理論的には、単一のディスクブロック（512バイト）を読み書きできますが、そうではないに違いありません。したがって、4Kと1.5K（通常のイーサネット）では、ほとんどの要求をパケット数の3分の1で満たすことができます。これは、勝利となるはずであり、場合によっては目立つものですらあります。
この記事はあなたの懸念とはまったく関係がありません。 SQLServerが認識するアプリケーショントラフィックについて説明します。一方、ストレージ接続について質問があります。サーバーのiSCSIイニシエーターが認識するトラフィックです。
だから、まず、記事を忘れてください。
次に、「ジャンボフレームを有効にする」ことを推奨しないストレージベンダーのベストプラクティスやホワイトペーパー、またはマニュアルをまだ見ていません。
アプリケーションは関係ありません。プラットフォームは関係ありません。 iSCSIはジャンボフレーム、期間が好きです。