プラットフォームから実行された特定のクエリがあり、すでにEnterpriseがインストールされているボックスで多くのCPUを消費するため、ResourceGovernorは優れたソリューションのように思われました。 Devサーバーでの構成に取り組んでいますが、期待した動作が見られません。サーバーには4つのコアと16GBのメモリがあり、Server 2012R2上のSQLServer2014を使用しています。リソースプールとワークロードグループを次のように変更しました。
USE [master]
GO
ALTER RESOURCE POOL [CRTestRP] WITH(min_cpu_percent=5, max_cpu_percent=5, cap_cpu_percent=5,
min_memory_percent=0, max_memory_percent=100, AFFINITY SCHEDULER = AUTO, min_iops_per_volume=0,
max_iops_per_volume=0)
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
GO
ALTER WORKLOAD GROUP [CRTestWG] WITH(group_max_requests=0, importance=Low, request_max_cpu_time_sec=0,
request_max_memory_grant_percent=25, request_memory_grant_timeout_sec=0, max_dop=1) USING [CRTestRP]
GO
ALTER RESOURCE GOVERNOR RECONFIGURE
リソースの競合がない限り、リソースガバナーは開始されないことを理解しています。効果をテストするために、HammerDBを使用してCPUを平均88%に引き上げる、サーバー上にシミュレートされたワークロードを作成しました(これは、可用性グループのセカンダリレプリカを保持するノードであるため、私のクエリのみです)。テストクエリが分類関数によってワークロードグループに正しく配置されていることを確認しました。いくつかのテストクエリを実行する準備ができています。
HammerDBを開始して数分間実行した後、CPUを集中的に使用するクエリの1つを開始しました。それは効果的にそれを抑制し、CPUを最大5%に保ちますが、同じクエリを実行する接続を追加すると、そのワークロードグループのCPU使用率が急上昇し、デフォルトプールに悪影響を及ぼします。
上のグラフでは、CPUは時間枠全体で100%です。問題のクエリは、ワークロードグループのMAXDOP 1がなければ並列になるという事実を除けば、関連性がないようです。
他の誰かがこの行動を見たことがありますか?リソースガバナーで成功した人はいますか?私が本当に望んでいたのは、これらのクエリが一度にすべてを組み合わせた場合に、特定の量を超えるCPUを使用することは決してできないということでしたが、そうではないようです。 CPU%が「競合」を構成するものに対して構成可能な値があるはずのようです。
いずれにせよ、ご協力ありがとうございました!
私は実際にこれについてマイクロソフトと契約することになりました。エンジニアが説明したのは、RGは同じインスタンスでOLTP vs. OLAPタイプのワークロードをスロットリングするのにうまく機能しないということです。ケースは、数千の小さなクエリが1〜2ミリ秒かかり、ときどきクエリが6〜7秒かかり、より長いクエリが抑制したいサーバーでした。彼はこれがバグであり、将来のリリースで修正されることを認めました。どうやら、RGはこれらの特定の問題を解決するためにSQL2016でゼロから書き直されています。