「クライアント処理時間」が長いためにリモートSELECTステートメントが遅いが、ローカルでは速い

実稼働サーバー（SQL Server 2008、非常に強力なマシン）に接続している間、このSELECTステートメントは2秒かかり、すべてのフィールド（合計4 MBのデータ）を返します。

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

同じネットワーク上の他のボックスから（SQL認証またはWindows認証を使用して接続）、同じクエリに1分8秒かかります。

私はこの非常に単純なステートメントでテストして、それが索引付けの問題やクエリ関連の問題ではないことを示しています。（現在、すべてのクエリでパフォーマンスの問題があります...）

行はチャンクで提供され、一度にすべてではありません。最初の行をすぐに取得し、行のバッチが入るまで1分以上待ちます。

クエリがリモートボックスから実行されたときのクエリのクライアント統計は次のとおりです。

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

「クライアント処理時間」が合計実行時間に等しいことがわかります。

実際のデータの転送に長い時間がかかる理由を診断するために実行できる手順を誰かが知っていますか？

マシン間のデータ転送速度を制限または制限するSQL構成パラメーターはありますか？

あなたの情報に基づいて、あなたの問題は間違いなくネットワークに関連しています。そのため、ネットワークの専門家（私は私ではありません）に対処する必要があります。

役立つかもしれないもの：

• より高速なNICカード（SQLサーバー上）。
• サーバー（WebサーバーとSQL Server）間の割り当てられた/特定のNICカード/サブネットの追加。

WebサーバーはSQLサーバーと同じサブネットにありますか？

それらの間にルーター/ブリッジなどはありますか？

SQLサーバーで可能な変更は多くありません：

• 出力データは、SQL Serverが独自のMS "TDSプロトコル"を使用して送信しています。
• TDSバッファのデフォルトサイズは4 KBです。MSDBの「ネットワークパケットサイズオプション」を参照してください。
• データの圧縮（SQL Serverまたは外部アプリケーションを使用）-データの性質によって異なります。

デフォルトサイズを使用しています：統計を確認してください： "サーバー1216から受信したTDSパケット"（4MB / 1K = 4KB）。はい、TDSバッファーのサイズは変更できます。Googleで確認：「TDSプロトコルバッチサイズ」

トピックに関する良い議論：「SQLのネットワークパケットサイズは実際に往復トラフィックを決定するのですか？」

ただし、TDSパッケージのサイズを変更すると（必然的に）予測できない影響が生じるため、例外的な場合にのみ本番環境で使用してください。

アーキテクチャの変更または中間層でのデータのキャッシュの導入も役立ちます。

この問題は解決されました。

これはネットワークの問題であり、SQLボックスは10 GB /秒の NICカードではなく、100 MB /秒の NICカードを使用していました...

正しいネットワークカードを使用するようにネットワーク構成を変更すると、問題が修正されます。これで、プロダクションSQLボックスとネットワーク上の他のボックスからのすべてのクエリで同様のパフォーマンスが得られます。

皆さんの助けに感謝します。

最初に読んだとき、ネットワーク遅延の問題が発生しているようです。Network Perfmonカウンターのいくつかを見ましたか？これらは、ネットワークで何が起こっているかをある程度示す場合があります。

どのPerfmonカウンターを監視する必要があるか、およびそれぞれの意味を引用してください。

ネットワークIO

ネットワークI / Oを測定するには、次のカウンターを使用できます。

ネットワークインターフェイスバイト合計/秒

しきい値：ネットワーク帯域幅の80％を超える持続値。

重要性：このカウンターは、各ネットワークアダプター上でバイトが送受信される速度を示します。このカウンターは、ネットワークアダプターのトラフィックが飽和しているかどうか、および別のネットワークアダプターを追加する必要があるかどうかを知るのに役立ちます。問題を迅速に特定できるかどうかは、ネットワークのタイプと、帯域幅を他のアプリケーションと共有しているかどうかによって異なります。

ネットワークインターフェース受信バイト/秒

このカウンタは、各ネットワークアダプタを介してバイトが受信される速度を示します。総帯域幅の一部として着信データのレートを計算できます。これは、クライアントからの着信データを最適化する必要があること、または着信トラフィックを処理するために別のネットワークアダプターを追加する必要があることを知るのに役立ちます。

送信されたネットワークインターフェイスバイト数/秒

このカウンターは、各ネットワークアダプターを介してバイトが送信される速度を示します。総帯域幅の一部として着信データのレートを計算できます。これは、クライアントに送信されるデータを最適化する必要があること、または送信トラフィックを処理するために別のネットワークアダプターを追加する必要があることを知るのに役立ちます。

ServerBytes合計/秒

この値は、ネットワーク容量の50％を超えてはなりません。

このカウンタは、ネットワーク上で送受信されたバイト数を示します。より高い値は、ボトルネックとしてネットワーク帯域幅を示します。すべてのサーバーの合計バイト数/秒の合計がネットワークの最大転送速度にほぼ等しい場合は、ネットワークをセグメント化する必要があります。

プロセッサ％割り込み時間

このカウンタは、プロセッサがハードウェア割り込みの受信と処理に費やした時間の割合を示します。この値は、ネットワークアダプターなど、割り込みを生成するデバイスのアクティビティの間接的な指標です。

ネットワークインターフェース（*）出力キューの長さ

このカウンターは、ネットワークアダプターで待機しているスレッドの数を確認します。ネットワークアダプターで待機しているスレッドが多い場合は、システムがネットワークI / Oを飽和させている可能性が高いです。これは、ネットワーク遅延またはネットワーク帯域幅が原因であると考えられます。

出力キューの長さは、出力パケットキューの長さ（パケット単位）です。これが2より長い場合、遅延が発生するため、可能であればボトルネックを見つけて解消する必要があります。この実装では、要求はネットワークドライバーインターフェイス仕様（NDIS）によってキューに入れられるため、これは常に0になります。

いくつかの予備的な質問：1）サーバーには、製品上にSQLクライアントがあります。サーバーマシンがセットアップされましたよね？同じマシンにあるクライアントから同じクエリを実行すると、2秒で完了しますか？これをやろうとしましたか？ほんと２秒？2）本番環境の構成が変更された（または本番サーバーが他のネットワークに移動した/サーバー全体の再構築が完了した）とのことですが、そうですか？古い実稼働環境でのクエリの消費時間はどれくらいでしたか？

同じネットワーク上の他のボックスから...同じクエリには1分8秒かかります。3）クエリが返され、指定されたネットワーク内の任意のマシン（特定のマシンを除く）にあるクライアントから約70秒でクエリが返されます。私は正しく理解しましたか？3.1ちなみに、このクエリを使用するタイミングは、ビジネスで許容されますか？4）ただし、クエリ出力の消費時間を使用している特定のクライアントマシンについては、次のように指定しています。クライアント実行時間15:30：48 15分？（そして今回は明らかに受け入れられません）？正しい？5）それで、問題は単一のクライアントマシンに限定されますか？または、（新しい環境の）任意のクライアント/中間層などのマシンに？6）pingによって示される遅延は何ですか？クライアントコンピュータからサーバーへ？7）あなた（またはネットワーク管理者）は、双方向で（クライアントからサーバーへ、サーバーからクライアントへ）tracertを実行しましたか？ホップ数は？合計時間は何ですか？8）古い本番ネットワークは生きていますか？PingとTracerouteを使用して比較できますか？クライアントとサーバーの間の時間とホップは何でしたか？

好奇心から：これはクエリの例ですか？またはクエリの正確な表現？クエリには本当にWHERE句が含まれていませんか？これは非常に珍しいことだと私に同意します。テーブルにクラスター化インデックスがあるか、ヒープですか？テーブルには全部でいくつの行が含まれていますか？テーブルは非常に断片化されていますか？好奇心から：SELECT TOP NNNを選ぶ理由 ROWCOUNT NNNを設定してからSELECT *を選択しないのはなぜですか？このクエリは、クライアントによって1日に何回発行されますか？1？100？1MLN？基礎となるデータは静的ですか、動的ですか？どれくらい（1日あたり0.01％？1日あたり1％？1日あたり10％？）クエリの出力はプログラムで処理されますか？（ユーザーではないのですか？）中間層にキャッシュ/保存されないのはなぜですか？ありがとう、アレクセイ