11

約 40 の異なる (それぞれ約 1 ～ 5 GB) データベースを持つ SQL サーバーがあります。サーバーは、32Gigs の RAM を備えた 8 コア 2.3G CPU です。27Gig は SQL Server に固定されています。CPU 使用率はほぼ常に 100% に近く、メモリ消費は約 95% です。ここでの問題は、CPU が常に 100% に近く、その理由を理解しようとしていることです。

このスクリプトを使用して、どのデータベースが高 CPU に寄与しているかを確認するための最初のチェックを実行しましたが、実際に CPU を消費しているものについて詳細に実証することはできませんでした。トップ クエリ (すべての DB から) は、完了するまでに約 4 秒しかかかりません。IO もボトルネックではありません。

ここでメモリが犯人でしょうか？メモリ分割を確認したところ、OBJECT CACHE は SQL Server に割り当てられたメモリ (27G) の約 80% を占めています。多くのSPが関与している場合、それが正常であることを願っています。プロファイラーを実行すると、多くの再コンパイルが見られますが、ほとんどは「一時テーブルの変更」、「遅延コンパイル」などが原因であり、これらの再コンパイルがメモリ不足のためにプランがキャッシュからスローされた結果であるかどうかは明確ではありません

どんな考えでも感謝します。

4

2 に答える 2

22

SSMS でいくつかのレポートを確認できます。

インスタンス名/レポート/標準/トップセッションを右クリック

上位の CPU 消費セッションを確認できます。これにより、どの SQL プロセスがリソースを使用しているかが明らかになる場合があります。見回すと、他にもいくつかの CPU 関連のレポートがあります。もう少し DMV を指摘するつもりでしたが、すでに調べている場合はスキップします。

sp_BlitzCacheを使用して、上位の CPU 消費クエリを見つけることができます。IO などで並べ替えることもできます。これは、再起動の間に蓄積される DMV 情報を使用しています。

この記事は有望に見えます。

Ozar氏からのいくつかのスタック オーバーフローの利点。

編集: もう少しアドバイス...「わずか」5 秒間実行されるクエリは問題になる可能性があります。すべてのコアを使用して、実際に 8 コアを 5 秒 - 40 秒の「仮想」時間で実行している可能性があります。私はいくつかの DMV を使用して、そのコードが何回実行されたかを確認し、その 5 秒の合計を確認するのが好きです。

于 2012-09-17T21:30:53.300 に答える