CPU使用率が高い?―謎のスパイクを追え!

EnterpriseZine / 2014年4月11日 0時0分

▲図5 カラム名の後に続く空白は編集しています。一画面に収まらないので。

 過去に担当した案件を漁っていて、「そういえば、こんなことあったなぁ」というものを見つけました。SQL Serverが稼働しているサーバーのCPU使用率が、なぜか定期的にスパイクするというものです。

●案件の概要

 お客様はSQL Serverの稼働状況を監視するため、SQL Server AgentのジョブからDMVへのクエリを定期的に発行し、その結果をテキストファイルに保存していました。お客様曰く、「アプリケーションが稼働していないにもかかわらず、CPU使用率が定期的にスパイクしているので、犯人となりそうなのはこのSQL Server Agentのジョブぐらいしかいないと思う。」とのことでした。

■犯人のプロセスは特定、しかし…

 SQL Server Agentジョブの定義を頂いたので、早速自分の環境でも同じ現象が発生するかどうか環境を構築してみました。採取するDMVごとにジョブが定義されており、その実行間隔はまちまちです。それぞれのジョブが実行を開始されるのを待って、パフォーマンスカウンターを観察してみました。

 すると、しばらくしてからCPU使用率を表すパフォーマンスカウンターの値が跳ね上がりました。なんとも、あっさりと現象が再現したのです。この時に観察していたパフォーマンスカウンターはサーバーのCPU使用率を表すものでしたので、今度はどのプロセスがこのスパイクを引き起こしているのかを、プロセス単位のパフォーマンスカウンターで観察してみることにしました。スパイクする時はユーザーモードのCPU使用率が高いことを確認していたからです。今の時点で怪しいのは、SQL Serverのプロセスか、SQL Server Agentのプロセスのどちらかですから、観察するのはこの2つのプロセスに絞りました。

 パフォーマンスカウンターをセットして、スパイクを引き起こす何らかのジョブが実行されるのを待ちます。どれほどの間隔だったかは記憶が定かではありませんが、しばらくしてから、やっぱりまたスパイクしました。跳ね上がったカウンターは、SQL Serve Agentのプロセスです。

 これで犯人のプロセスは特定できました。しかし、SQL Server Agentの何の処理がスパイクを引き起こしているのか、また、どのジョブが実行されたときに発生するのかがわかっていませんでしたので、これらのいずれかを調査しようと考えました。

この記事に関連するニュース

トピックスRSS

ランキング