私のサイトの Web フロントエンドとデータベースは 2 つのサーバーに分かれており、1000M LAN で接続されています。
ほぼすべてのクエリの応答時間は 800 ミリ秒を超えています。単一のサーバーに展開すると問題が発生しないため、クエリがすべて正常であることを確認できます。
ウェブサイト/asp.net 2.0 データベース/sql server 2000
答え1
DNS が (キャッシュされているはずの) IP アドレスに 800 ミリ秒の遅延を引き起こしている場合は、ネットワーク設定に重大な問題があります。私の意見では、ping を使用すると、それが問題であるかどうかを確認できます。
パケットが 2 台のコンピュータ間で効率的なルートを使用していることを確認するには、traceroute を使用します。これは簡単に実行できるので、他の操作を行う前に試してみる価値があります。ルートにホップが多数ある場合 (2 ホップや 3 ホップ以上)、ネットワーク担当者を見つけて、その理由を尋ねてください。
SQL ネットワークの問題をトラブルシューティングする場合は、"SELECT GETDATE()" のような非常に単純なクエリを使用し、SQLCMD.EXE のような単純なクエリ ツールを使用するのが最適です。単純なクエリとは、サーバーがクエリの解析に多くの時間を費やす必要がなく、重大なロックやブロックも発生せず、クエリによってネットワーク経由で何百万行ものデータが返されることもありません。単純なクエリ ツールを使用すると、IIS が何を実行しているか、または実行していないかを心配する必要がありません。SQLCMD.EXE、OSQL.EXE、または同様のツールが IIS サーバーにインストールされていない場合は、SQL Server への接続をテストするための小さな psh または vbs スクリプトを作成する価値があるかもしれません。IIS サーバーにそのようなアクセス権がない場合は、その単純なクエリを実行して結果と実行にかかった時間を返す特別な ASP ページを作成することもできます。
問題を推測すると、次のようになります-> 特に古い機器やドライバーの場合は、NIC の「自動ネゴシエーション」設定に頼らないでください。両方のカードを手動で同じ設定に設定します。
面倒なことだとは思いますが、ネットワーク担当者が困惑していた同様の問題を 10 件ほど解決したのを個人的に見てきました。(結局のところ、これらはサーバーであり、多数の異なるスイッチに接続されてリンク速度やデュプレックス設定を再ネゴシエートする必要が生じるようなものではありません。)
パフォーマンス モニターを使用して、NIC のデータ レート (MB/秒単位) を観察することでも、この問題を確認できます。ベースラインを確立したら、NIC の設定を変更して再度観察します。
通常、これらの設定を「ライブ」で変更しても問題ありませんが、初めてこれらの設定をいじる場合は、ピーク負荷時に試すのはお勧めしません。テスト環境がある場合は、テスト環境で試すことをお勧めします。メンテナンス ウィンドウがある場合は、それが最適です。サーバーに NIC が 1 つしかない場合は、NIC がスイッチと通信できないように設定しないように注意してください。そうしないと、誰かにコンソールに物理的にログインするように依頼しなければならなくなり、誰にとっても残念なことになります。
答え2
考えられる理由は多数あります。たとえば、ネットワーク アダプタ ドライバーの 1 つに問題がある可能性があります。
SQL 接続がボトルネックになっているのか、それとも一般的なネットワークの問題なのかを確認する必要があります。Web サーバーから「select getdate()」コマンドを発行して、すべてのクエリが影響を受けているかどうかを確認してください。
データベース サーバーへの ping も遅いですか? また、サーバー名の代わりに IP アドレスを使用してみてください。DNS 解決の問題である可能性があります。