お客様の本番環境に奇妙な問題があります。 SQLサーバーが仮想サーバー上で実行されていることを除いて、インフラストラクチャの詳細を説明することはできません。データ、ログ、およびファイルストリームファイルは別のストレージサーバーにあります(データとファイルストリームは一緒になり、別のサーバーにログオンします)。
ローカルテスト環境では、次の期間で実行される特定のクエリが1つあります。
- まず、キャッシュをクリアします
- 300ms(最初は時間がかかりますが、それ以降はキャッシュされます。)
- 20ms
- 15ms
- 17ms
お客様の実稼働環境では、SQL Serverの方が強力です。これらは期間です(キャッシュをクリアする権限がありませんでした。明日これを試してみます)。
- 2500ms
- 2600ms
- 2400ms
お客様の実稼働環境のサーバーはより強力ですが、仮想サーバーはあります(私たちにはありません)。
原因は何でしょうか...
このパフォーマンスの問題にどのように取り組みますか?
編集:
データセットが等しいかどうか、そしてそうであるかどうかを私に尋ねる人もいます。私は彼らのデータベースを私たちの環境に復元しました。これが私が最初に見たものだったのは事実です。 (@Everyone:多くの人が最初に考えることになるので、編集を追加しました)。
原因としては、十分なメモリ、断片化、物理ストレージのほか、並列度の設定の違い、競合、テーブルサイズの違い、統計の違い、SQLパッチレベルの違いなどが考えられます。
したがって、実際にはwhatが間違っているかどうかについての質問ではなく、どのように判断するか なにが問題ですか。私の通常の推奨事項、私の経験では基本的に 'ではないものはthisまたはthat、 待機とキューの方法論 を使用することです。これは、最終的に原因を特定するかなりの方法のアプローチであり、それによって解決策が得られます。
メモリ、CPU、ネットワーク、またはディスクの競合である可能性がありますが、顧客のデータセットは大きいですか?
最初のステップは、クエリ自体の実行プランを取得して、行をスキャンしていないことを確認することです。彼らのデータベースサーバーは強力であるとすでに言っているので、最初にクエリを最適化する必要があります。 SQL Serverクエリアナライザは、これに最適なツールです。
システムと同じデータであっても、統計が古くなっていると、異なるクエリプランが生成される可能性があります。 EXEC sp_updatestats
を実行して、それが違いを生むかどうかを確認します。
以前はこれを行うサーバーがありました。どうやら、誰かがデータベースファイルをRAID 3アレイに設定したようです...お勧めできません!
もちろん、実際には何でもかまいませんが、ディスク構成を確認してください。
それはこれらのいずれかである可能性があります。ある種のSANを使用しているように聞こえるので、ネットワークが遅い(またはネットワーク上の問題)可能性もあります。
データの規模は、顧客環境とテスト環境で同じですか?これは多くの開発者が犯す間違いであり、本番環境のデータの規模をシミュレートしていないデータセットのパフォーマンスをテストします。
ProfilerとPerfMonにアクセスできる場合は、問題をかなりすばやく絞り込むことができます。
これをデバッグするための推奨される方法は、SQL Serverパフォーマンスカウンター(Start/Run/perfmon.exe)を調べることです。どれがあなたのケースに関連しているかを知るのに少し時間がかかりますが、それは間違いなく価値があり、このタイプの問題を正確に特定するのに役立ちます。
ここに私に似合ういくつかのクイックリンクがあります、 Google もっとたくさん知っています:
使用している仮想化テクノロジーによっては、特にディスクI/Oに関して、仮想サーバーのパフォーマンスが大幅に低下する可能性があります。仮想マシンでは、ディスクアクセスは、仮想ディスク上のコマンドを物理ディスク上のコマンドに変換するエミュレーションまたはドライバーレイヤーによって処理される場合があります。このエミュレーションでは、多くの場合、大幅な追加の遅延が発生し、基盤となるディスクアレイを適切に利用できない場合があります。
本番サーバーはテストセットアップと同じですか?
データログとファイルシステムがストレージサーバー上にあるとおっしゃっていますが、それは何に接続されていますか?ファイバーチャネル、10/100/1GB? scsi?ファイバチャネル以外は遅くなります!!!
ストレージサーバーはデータベースサーバー専用ですか?あなたは資源のために戦っていますか?