スループットを向上させるSQLサーバー接続文字列のネットワークパケットサイズ
2つのSQLサーバー間でネットワークを介して比較的大量のデータを移動するデータロードジョブがあります。サーバーは同じサブネット上にあり、サーバー間にはスイッチしかありません。データは、いくつかの大きなvarcharフィールドとxmlフィールドで構成されています。
スループットを向上させるため。接続文字列でネットワークパケットサイズをデフォルトの4096から32627に変更しようとしました。しかし、それはパフォーマンスを助けていないようです。私は問題を疑っていますが、私たちはギグイーサネットを実行していますが、「ジャンボフレーム」が有効になっていません。
これを確認するために、2つのpingテストを試しました。
ping -l 1400 -f pdbsql01dul
作品
ping -l 4096 -f pdbsql01dul
パケットはフラグメント化する必要がありますが、DF set。
ご覧のとおり、最大パケットサイズは約1400のようです。
私の質問は、ジャンボフレームが〜8096の場合、ネットワークパケットサイズをそれより大きく設定する利点はありますか？
接続が問題のサーバーに対してローカルである場合、これは変わりますか？
必要なのは、イーサネットネットワークのMTU設定を1500から4096の北に増やす必要があるということです。これらの設定は通常、[ドライバー設定]ページで設定します。優れたネットワークを実現するには、同じイーサネット上のすべてのデバイス（すべてのイーサネットスイッチを含む）に同じMTU設定を設定する必要があります。
（ソース： sysadmin1138.net ）
それはあなたが私のサーバーの1つでそれを変更するところです。
それは役立ちますか？それは確かにできます。パケットの断片化が少ないということは、トラフィックストリームを再構築するためのTCPスタックでの作業が少ないことを意味します。桁違いではないかもしれませんが、役立つ可能性があります。
サーバーのローカル接続は、TCP接続ではなくパイプを使用し、おそらくこの変更による影響を受けないと思います。
試すことはできますが、それが大いに役立つとは思えません。プロトコルとしてのTDSは、高スループットのために設計されたことはありません。 2つのSQLサーバーインスタンス間でデータを移動する場合は、代わりに Service Broker を使用することを検討してください。代わりに、そのネットワークスタックはTDSスタックよりもはるかに高いトラフィック指向になっています。これが、ミラーリングがスタンバイミラーサーバーと通信するためにSSBネットワークスタックを選択する理由です。さらに、SSBのデータ移動セマンティクスは、リンクサーバーよりもはるかに優れており、通常はカスタムクライアントアプリよりも優れています。
Tcpやフレームなどについてコメントすることはできませんが、SQL 6.5クライアントツールを必要とする一部の悪質なアプリについては、SQL Serverネットワークパケットサイズを一度しか設定していません。
これは、それらの "それをしない"設定の1つです。