SQL Serverの1つのインスタンスを実行している物理サーバーがあります。
このサーバーがCPU使用率100%で実行されていることがよくあります。
私のITチームはこれに満足しておらず、32コアのうち2コアをOS用に予約することを提案しました。
これは問題なく機能し、最大使用率のピークは90%未満になりました。さらに、さまざまなユーザーからの遅いデータ取得は報告されなくなりました。
SQLリソースガバナーの代わりに、この方法でWSRM(Windowsシステムリソースマネージャー)を使用しない理由はありますか?
定義したアプローチを使用しない理由はありますか?もちろんです。
あなたが車を買ったと想像してください-あなたが50MPHに達するとエンジンがオーバーヒートし始める車です。この状況に対するあなたの反応は、人為的に車を49MPHに制限することですか、それともエンジンの故障が何であるかを知ることですか?
車を49MPHに制限する必要があるのはなぜですか?製造業者は、それが80MPHまで高速で運転できると述べました-あなたがあなたの車を速く運転したいので、あなたはそれをこの速度にしたいのです-それがいまいましい過熱の問題のためでなければ。
あなたが買った車も本当に、本当に高価でした。あなたはそのお金を無駄にしないように、各エンジンシリンダーは最大限に利用される必要があります!
SQL ServerによるCPUへのアクセスを人為的に制限することで、パフォーマンスが失われます。 CPUがOSで使用できるようにすることでパフォーマンスの問題を一時的に解決した可能性がありますが、実際の質問には答えていませんSQL ServerがCPUを100%使用している理由は何ですか?
私のアドバイスは次のとおりです。
本当の問題が何であるかを調べ、それを修正します。実質的にクラッジであるもので問題をカバーしないでください。問題[〜#〜]ウィル[〜#〜]サーバーのワークロードが成長に伴って自然に増加するときに、再び現れて、一線を下に押しつぶします。
一時的な修正として、リソースガバナーを使用して、使用されるCPUを下げることができます実際の問題が見つかるまで
Erik Darling 質問のコメントでWSRMを使用しない最大の実用的な理由に言及しました:
...他のプロセスでのCPU使用の相互制限はありません。 SQL Serverはこれらの2つのコアを使用しない場合がありますが、他のものはSQL Serverが使用している他の30を使用する場合があります。本当に、それはくだらないことです。
これで問題が解決した場合は、それを使用してください。私たちはすべて忙しいので、特定の問題に費やす時間は限られています。 ideal解決策は、CPUをユーザーが気付く問題のポイントにまで駆り立てる根本的なクエリ/問題を修正することです(ジョージは彼の- 優れた答え )。
エリックは続けて言う
さらに、SQL Serverのライセンスを支払います。
ビジネスの観点からは、これはおそらくWSRM契約の最悪の部分です。明示的に使用されていない2つのコアに対してコアごとのライセンスを支払うことになります。これを書いている時点では、それは(標準とエンタープライズに応じて)テーブルに残っている$ 3kまたは$ 14,000です。