概要
Microsoft SQL Server 2005 は、高解像度 CPU カウンターを使ってマイクロ秒のタイミング機能を提供します。 マイクロ秒は1秒 (または1ミリ秒の millionth) です。 ただし、CPU 周波数を変更するテクノロジを使用している場合は、SQL Server のタイミング値が正しくないことがあります。 たとえば、次のいずれかのテクノロジを使用している場合に、この問題が発生する可能性があります。
-
CPU ステッピング
-
AMD Cool'n'Quiet 技術
-
さまざまな電源設定
この記事には、この問題の回避に役立つメソッドと追加情報が記載されています。
現象
サーバーの実行、解析、コンパイルの時間を表示するために [統計時間の設定] ステートメントを使用すると、正しくない値が表示されることがあります。 たとえば、SQL Server の実行時間の経過時間が CPU 時間よりもはるかに多いことがわかります。 この問題は、パフォーマンスのチューニングの精度に影響する可能性があります。 この問題は、サーバーの "概要" セクションに記載されているテクノロジのいずれかを使用している場合に発生します。
原因
この問題は、これらのテクノロジを使用するときに CPU 周波数が変更されるために発生します。 SQL Server 2005 は、高解像度 CPU カウンターを使ってマイクロ秒のタイミング機能を提供します。 エネルギーを節約するために CPU 周波数が変更され、発熱量が減る場合、計算された期間が間違っている可能性があります。
解決方法
Service pack の情報
この問題を解決するには、SQL Server 2005 の最新の service pack を入手してください。詳細については、以下の記事の番号をクリックして、Microsoft サポート技術情報の記事を参照してください。
913089 SQL Server 2005 の最新の Service Pack を入手する方法注 SQL Server 2005 Service Pack 3 以降の service pack では、プロセッサのタイムスタンプは使用されません。これらのバージョンの SQL Server 2005 では、精度が1ミリ秒のより高い信頼性のタイマーが使用されます。
状態
この問題は、SQL Server 2005 Service Pack 3 で最初に修正されました。
回避策
SQL Server 2005 では、正確なパフォーマンスチューニングを実行するために既知の安定したデータポイントが必要です。 コンピューターで動的 CPU 周波数調整が有効になっている場合は、SQL Server のパフォーマンスを監視してチューニングする前に、Cpu の周波数を一定に保つことができます。 これを行うには、以下の方法を実行します。
Cpu が最大周波数で維持されるように、コンピューターの電源設定を構成する
これを行うには、次の手順を実行します。
-
[ スタート] をクリックし、[ 実行] をクリックして、「 Powercfg」と入力し、[ OK]をクリックします。
-
[ Power Options のプロパティ] ダイアログボックスで、[電源設定] の一覧の [常にオン] をクリックします。
-
[OK] をクリックします。
ドリフトが発生する場合があります。 ドリフトは、CPU 周波数の値の相違を示します。 詳細については、「ドリフト」セクションを参照してください。 この場合、電源設定を変更した後で、すべての Cpu の周波数を再同期するには、Microsoft Windows を再起動する必要があります。 コンピューターを再起動できない場合は、SQL Server プロセッサのアフィニティを有効にして、SQL Server のワーカースレッドが Cpu 間で移動しないようにします。 これを行う場合、CPU 周波数の値が異なる場合でも、コンピューターを再起動する必要はありません。 サーバー上のすべての Cpu に対して SQL Server プロセッサのアフィニティを有効にするには、サーバー上の論理プロセッサの数に応じて、別のマスクを使用する必要があります。 次の表は、シナリオの例を示しています。
|
CPU 番号 |
プロセッサのアフィニティを有効にするためのステートメント |
|---|---|
|
02 Cpu |
exec sp_configure ' affinity mask '、0x00000003GOreconfigureGO |
|
04 Cpu |
exec sp_configure ' affinity mask '、0x0000000FGOreconfigureGO |
|
8 Cpu |
exec sp_configure ' affinity mask '、0x000000FFGOreconfigureGO |
|
16 Cpu |
exec sp_configure ' affinity mask '、0x0000FFFFGOreconfigureGO |
|
32 Cpu |
exec sp_configure ' affinity mask '、0xFFFFFFFFGOreconfigureGO |
注: CPU 周波数のバリエーション機能を BIOS レベルで無効にできない場合があります。 さまざまなサードパーティ製ユーティリティで CPU 周波数を変更することができます。 一部の実装では、Cpu が最大限の電源設定を使用している場合でも、周波数調整が有効になります。 この場合は、SQL Server 2005 でパフォーマンスチューニングを実行するときに、サードパーティ製のユーティリティを無効にする必要があります。
サードパーティのユーティリティとドライバーを使用して CPU 周波数および CPU クロックカウンターを同期させる
まれに、CPU 周波数の問題を修正するために、システムによっては製造元からの更新が必要になることがあります。 システムに問題が発生している可能性がある場合は、システムに最新の BIOS、マイクロコード、およびファームウェアの更新プログラムがないかどうかを確認することをお勧めします。
詳細情報
Microsoft SQL Server 2000 および以前のバージョンの SQL Server では、Windows のタイミングメカニズムが使用されています。 タイミング機構では、ミリ秒の精度の値が使われます。 通常、この精度は 10 ~ 15 ミリ秒です。 ただし、有効桁数は55ミリ秒までにすることができます。 SQL Server クエリは、1桁のミリ秒またはマイクロ秒の期間内に頻繁に完了します。 この精度では、高解像度タイマーが必要です。 そのため、これらのバージョンの SQL Server では、一部のクエリの期間が0ミリ秒として報告されます。 そのため、以前のバージョンの SQL Server では、パフォーマンスを監視して SQL Server のパフォーマンスを調整することは困難です。 SQL Server 2005 は、高解像度 CPU カウンターを使ってマイクロ秒のタイミング機能を提供することで、精度を高めています。 「概要」セクションに記載されているテクノロジを使用すると、報告されたタイミングの値が間違っている可能性があります。 この問題は、次のオブジェクトおよび機能に影響する可能性があります。
-
トレースイベント:
-
アテンションイベント
-
ストアドプロシージャノードのイベント
-
TSQL ノードのイベント
-
オブジェクトノードのイベント
-
トランザクションノードのイベント
-
-
動的管理ビュー:
-
sys.dm_exec_query_stats
-
sys.dm_exec_requests
-
sys.dm_exec_sessions
-
sys.dm_io_pending_io_requests
-
sys.dm_os_ring_buffers
-
sys.dm_os_sys_info
-
sys.dm_io_virtual_file_stats
-
sys.dm_os_wait_stats
-
-
統計時刻の設定ステートメント
-
Sysprocessesシステムテーブル
Sql server 2005 Service Pack 2 (SP2) をインストールした後、sql server は、高解像度タイマーが Cpu 間で同期されていないことを SQL Server が検出したときに、エラーログにエラーメッセージを記録します。 このエラーメッセージは、パフォーマンスのタイミングが正確でない可能性があることを示します。ユーザーは、パフォーマンスデータを慎重に使用する必要があります。エラーメッセージのテキストは、次のいずれかのエラーメッセージになります。
エラー メッセージ 1
スケジューラ id 2 の CPU のタイムスタンプカウンターは、他の Cpu と同期していません。
エラー メッセージ 2
CPU タイムスタンプの頻度が、ミリ秒あたりの191469から1794177チックに変更されました。 新しい頻度が使用されます
SQL Server は、リアルタイムスタンプカウンター (RDTSC) 命令を使って、64ビットの CPU ティック数を取得します。 この値を CPU 周波数で割ると、値をミリ秒の値に変換できます。 CPU 周波数の変更またはドリフトが発生すると、タイミングのバリエーションが発生する可能性があります。
CPU ステッピング
CPU ステッピングは、CPU 周波数の計画的な変更として定義されます。 CPU ステッピングは、Intel SpeedStep テクノロジーまたは AMD PowerNow とも呼ばれていることがあります。 面. CPU のステッピングが発生すると、電力を節約し、熱の出力を抑えるために、CPU 速度が 50 MHz の小さい単位で増加または減少する可能性があります。 同じ non-uniform memory access (NUMA) ノード内の Cpu は、周波数を個別に調整するわけではありません。次の表は、CPU ステッピングの変更がタイミングの計算に与える影響を示しています。
|
アクション |
RDTSC の目盛り |
ミリ秒あたりのタイマー数 (頻度) |
ウォールクロック時間 |
|---|---|---|---|
|
バッチの開始 |
件 |
200 |
0 |
|
頻度のステップダウン |
200 |
100 |
1ms |
|
バッチの終了 |
500 |
3ms |
|
|
合計 |
500 |
4ms |
SQL Server は、start と end RDTSC ticks の両方で RDTSC ticks をキャプチャします。 次に、SQL Server は頻度の値によってティックを分割します。 この例では、200または100の周波数値を使用するときに、次のタイミング計算が行われます。
-
頻度 200: 500/200 = 2.5 ms
-
頻度 100: 500/100 = 5 ミリ秒
タイミングの計算は、実際のウォールクロック時間4ミリ秒と一致しません。 RPC: Completedトレースイベントでこの計算を使用している場合、[期間] と [終了時刻] のデータ列は正しく報告されません。 RPC: Completedイベントは、開始ウォールクロック時間と CPU ティック数をキャプチャします。 SQL Server 2005 で Windows の提供よりも時間のかかる時間を短縮するには、SQL Server のトレースの 期間 データ列と 終了時刻 データ列を、経過した CPU ティック数を使って計算します。 [終了時刻] 列は [開始時刻] 列に [期間] 列を追加して計算されます。 この例では、 終了時刻 列は、開始時刻に 2.5 ms または5ミリ秒のどちらかを誤って追加しています。
ジャイロ
ドリフトは、CPU クロック値の相違を示します。 複数の Cpu を搭載したシステムでは、同じ時点で異なる CPU クロック値を生成できます。 一般的ではありませんが、Cpu では時間の経過によってクロックの分離が発生する可能性があります。次の例は、ドリフトの変化が SQL Server トレースの duration データ列の結果にどのように影響するかを示しています。 この例では、CPU 周波数がミリ秒あたり200タイマー刻みで安定していることを前提としています。 次の表は、このシナリオのイベントを示しています。
|
アクション |
Windows のスケジュールされた CPU |
CPU 1 RDTSC |
CPU 2 RDTSC |
ウォールクロック時間 |
|---|---|---|---|---|
|
バッチの開始 |
件 |
100 |
1100 |
0 |
|
バッチの終了 |
両面 |
900 |
1900 |
4ミリ秒 |
|
合計 |
4ミリ秒 |
SQL Server は、開始点と終了点の両方で RDTSC ticks をキャプチャします。 次に、SQL Server は頻度の値によって RDTSC のタイマーを分割します。 この例では、Windows は2つの異なる Cpu に SQL Server ワーカースレッドをスケジュールしていました。 バッチをサービスする SQL Server ワーカースレッドは、最初の CPU (CPU 1) で最初に実行されています。 ただし、バッチの実行はある時点で中断され、SQL Server は保留中のキューにバッチ実行を送信しました。 SQL Server が、このバッチを実行する SQL Server ワーカースレッドを再実行可能なキューにもう一度送信すると、Windows は2番目の CPU (CPU 2) で実行するスレッドをディスパッチします。 SQL Server ワーカースレッドが CPU 2 で実行されました。 CPU 誤差のため、CPU 2 からキャプチャされた終了目盛りの値は、900ではなく1900でした。 SQL Server プロセッサのアフィニティを有効にすると、この動作を回避できます。 この例では、次のタイミング計算が使用されます。
-
間違って報告された値: (1900 – 100 = 1800)/200 = 9 ミリ秒
-
正しい値: (900 – 100 = 800)/200 = 4 ミリ秒
RPC: Completedイベントのduration列の値は、4ミリ秒ではなく、9ミリ秒として報告されます。 この結果は、4ミリ秒の正しい値の倍精度の値になります。警告メッセージは、SQL Server 2005 に追加され、前に説明したパフォーマンス出力が信頼できない可能性があることを示します。 一部の状況では、SQL Server 2005 SP2 で、次の内容に関する警告メッセージが報告されることがあります。
-
警告メッセージの誤通知
-
ドリフトは、顕著なシステム効果を発生させることなく、数十ミリ秒になることがあります。
パフォーマンスに関連する出力を評価する場合や、パフォーマンスに関連する出力とウォールクロックのタイミングを比較する場合は、注意する必要があります。 その他のパフォーマンス上の問題がある場合は、通常、ドリフト警告メッセージは無視してください。 たとえば、次のような場合は通常、ドリフトの警告メッセージを無視できます。
-
プロセスは期待どおりに実行されています。
-
SQL Server クエリが予期しない durational パターンで実行されていない。
-
他のボトルネックの兆候は表示されません。
ただし、ドリフト警告メッセージを無視する前に、製造元に連絡して既知の RDTSC 問題が存在しないことを確認することをお勧めします。 トレースフラグ 8033 (– T8033) を使うと、SQL Server 2005 および SQL Server 2005 SP1 の元のリリースバージョンのレポート動作に戻ることができます。 SQL Server 2005 および SQL Server 2005 SP1 の最初のリリース版では、ドリフト警告メッセージは報告されません。 SQL Server 2005 または SQL Server 2005 SP1 の元のリリースバージョンを実行しても問題が解決しない場合は、通常、メッセージを無視することができます。
WAITFOR DELAY ステートメントが適切に機能するのはなぜですか? 定期的なシステムプロセスについて
タイムアウトメカニズムは、高解像度設計の影響を受けません。 SQL Server では、タイマーベースのアクティビティに高解像度タイマーは使用されません。 一部のタイムアウトアクティビティは、 GetTickCount 関数を使う低解像度タイマーに基づいています。 これらのタイムアウトアクティビティには、ロックタイムアウト、WAITFOR DELAY ステートメント、デッドロック検出などがあります。
詳細については、次の記事の番号をクリックして、Microsoft サポート技術情報の記事を参照してください。
938448 サーバーでデュアルコア AMD Opteron プロセッサまたはマルチプロセッサ AMD Opteron プロセッサが使用されている場合、Windows Server 2003 ベースのサーバーでタイムスタンプカウンターの誤差が発生することがある
895980 Windows Server 2003 および Windows XP では、QueryPerformanceCounter 関数を使用するプログラムが適切に動作しないことがあります。この記事で説明するサードパーティ製品は、Microsoft と関連のない他社の製品です。Microsoft は、これらの製品のパフォーマンスや信頼性について、明示または黙示に従わないいかなる責任も負わないものとします。
