web-dev-qa-db-ja.com

SQLServerが突然CPUのごく一部しか使用しなくなった

SQL Server2008を実行しているWindows2008 R2サーバーがあります。突然、SQLServerプロセスはCPU使用率が20％を超えることを拒否しています。先週の時点で、dbに対して重いクエリを実行すると、予想どおり100％の使用率になります。私たちはしばらくの間このサーバーを持っていました、そしてそれが突然この制限を持っているのは奇妙に思えます。この制限により、クエリに通常よりもはるかに長い時間がかかります。サーバー構成に（少なくとも知っている限り）変更を加えた人は誰もいません。

少し調べてみたところ、sys.dm_os_sys_memoryビューが見つかりました。これは、「使用可能な物理メモリが高い」ことを示しています。同時に、使用可能な物理メモリは339552kbですが、合計は4193848kbです。これはvmwareで実行されている仮想サーバーであることに注意してください。

最大CPU使用率を設定するSQLServerのどこかに設定がありますか？リソースガバナーの設定を見つけましたが、これはいつものように現在オフになっています。

最近、QuestSoftwareによるSpotlightfor SQLServerの使用を開始しました。今朝、再生データベースがこのサーバーに短時間配置されていたので、その直後に最初に問題に気づきましたが、これまでクエリを実行していなかったため、これが問題の原因であるかどうかはわかりません。開始しましたが、データベースは金曜日の午後に期待どおりに機能していました。 Windowsログには、SpotlightPlaybackDatabaseが作成されたときに次の設定が適用されたことが示されています。

  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションTORN_PAGE_DETECTIONをONに設定しています。
  • 02/21/2011 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションMULTI_USERをONに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションREAD_WRITEをONに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションAUTO_UPDATE_STATISTICSをONに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションAUTO_CREATE_STATISTICSをONに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションANSI_WARNINGSをOFFに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションCONCAT_NULL_YIELDS_NULLをONに設定しています。
  • 02/21/2011 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションRECOVERYをSIMPLEに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションQUOTED_IDENTIFIERをOFFに設定しています。
  • 2011/02/21 08：45：02、spid60、Unknown、データベースSpotlightPlaybackDatabaseのデータベースオプションAUTO_CLOSEをOFFに設定しています。

これらの設定の変更のいずれかによって、サーバー全体に適用される設定が変更されましたか？

編集＃1： SQL Serverを再起動することでこの問題を修正できましたが、そもそも問題が何であったかはわかりません。問題は解決されましたが、以前は気づかなかったioの問題を解決する必要があります。

編集＃2：問題が再発しました。解決策は、SQL ServerのSpotlightでトレース分析をオフにすることでした。これが、すべてを下にドラッグしていたものでした。

sql-servercpu-usage
6
hermiod

Sys.dm_os_waiting_tasksをチェックして、待機リソースが何であるかを確認します。基本的にwait_typeを見て、そこに何があるかを確認します。このクエリを実行して、結果を投稿してください。

select wait_type, sum(wait_duration_ms) sum_wait_duration_ms, avg(wait_duration_ms) avg_wait_duration_ms, count(*) waits
from sys.dm_os_waiting_tasks
group by wait_type

あなたは私が今朝話したのと同じような問題に苦しんでいるかもしれません 私のブログ 。

1
mrdenny

CPU使用率を管理することはできませんが、管理することはできます CPUアフィニティ 。つまり、誰かがSQL Serverを単一のCPUの使用に制限しましたか？

同じように、誰かが グローバルmaxdop設定 を変更しましたか？これにより、すべてのクエリが1つのCPUに制限されますが、単一のクエリは使用可能なCPUの1つで実行されます。

3
gbn

Gbnが述べたように、CPUアフィニティまたはMAXDOPの構成が変更されていないと仮定すると、いくつかの可能性があります。

1つ目は、インデックスまたは基になるテーブルデータの分布が大幅に変更されたため、クエリのクエリプランが変更されたことです。基になるテーブルのインデックスを最適化または再構築してみてください。

次に、メインデータベースファイルからデータを読み取るか、tempdbで作業する（RAMに対して大きすぎる場合、SQLがクエリの中間部分を格納する）I/Oバウンドになっている可能性があります。 perfmonを使用し、平均を監視します。ディスクキューの長さ。サーバー内の物理ディスクスピンドルの平均数よりも少ないはずです。 CPUが低いままで、「重いクエリ」中に起動した場合、CPUは単にディスクIOを待機しているため、100％で実行して有用な作業を行うことはできません。この場合、いくつかのオプションがあります。moreRAM（ディスクを使用する必要性を減らすため）、より高速なディスク（SSD？）、またはクエリ、インデックス、スキーマを最適化して削減するディスクIO。最後のオプションは、はるかに大きな影響を与える可能性があります（文字通り、100倍以上改善されます）。ただし、データ構造とクエリによっては、最も難しい場合もあります。SQL実行計画を確認してください。いくつかの本を買う。

3
rmalayter

実行できることの1つは、クエリを実行しているプロセスに何が起こっているかを正確に確認することです。 spidsアクティビティを監視し続け、最も一般的な待機タイプを確認する場合。ディスクの読み取り/書き込みが完了するまでCPUがクエリをアイドリングしていることを意味する、spidが待機しているdiskioなどのリソースがあることに気付くでしょう。

1
Mark Broadbent

そもそも何が原因かはわかりませんが、SQLServerを再起動することでこの問題は解決しました。返信ありがとうございます。

0
hermiod