web-dev-qa-db-ja.com

SQL 2012でリソース管理クエリが抑制されている方法をトラブルシューティングする方法

ユーザー定義のリソースガバナープールで実行されているSQL 2012 SP1（ent）で並列化されたクエリがあり、実行されている同じクエリよりもはるかに遅い（ユーザー定義のプールでは125〜140秒= 2〜75倍遅い）。デフォルトのリソースプール。

クエリプランハッシュは2つの実行間で同一であり、統計ioはすべての操作で同じ値を返します。実行プランには追加の警告（両方とも警告）がないこと、およびクエリのメモリ許可が同じであることを確認しました。

ユーザー定義のプールワークロードグループ

<QueryPlan DegreeOfParallelism="4" MemoryGrant="2384096" CachedPlanSize="384" CompileTime="3608" CompileCPU="2712" CompileMemory="15672">
        <ThreadStat Branches="5" UsedThreads="20">
          <ThreadReservation NodeId="0" ReservedThreads="20" />
        </ThreadStat>
        <MemoryGrantInfo SerialRequiredMemory="5632" SerialDesiredMemory="2360768" RequiredMemory="28960" DesiredMemory="2384096" RequestedMemory="2384096" GrantWaitTime="0" GrantedMemory="2384096" MaxUsedMemory="93872" />
        <OptimizerHardwareDependentProperties EstimatedAvailableMemoryGrant="209715" EstimatedPagesCached="104857" EstimatedAvailableDegreeOfParallelism="4" />

デフォルトのプール

<QueryPlan DegreeOfParallelism="4" MemoryGrant="2384096" CachedPlanSize="384" CompileTime="3016" CompileCPU="2660" CompileMemory="15672">
            <ThreadStat Branches="5" UsedThreads="20">
              <ThreadReservation NodeId="0" ReservedThreads="20" />
            </ThreadStat>
            <MemoryGrantInfo SerialRequiredMemory="5632" SerialDesiredMemory="2360768" RequiredMemory="28960" DesiredMemory="2384096" RequestedMemory="2384096" GrantWaitTime="0" GrantedMemory="2384096" MaxUsedMemory="88768" />
            <OptimizerHardwareDependentProperties EstimatedAvailableMemoryGrant="209715" EstimatedPagesCached="104857" EstimatedAvailableDegreeOfParallelism="4" />

Total_worker_timeは、クエリ間でほぼ同じです。異なるように見えるのは、total_elapsed_timeだけです。待機はcxpacketです。この時点で、これはリソースガバナーがCPUやメモリを調整するために行っていることだと思います。ただし、スロットルの証拠は見つかりません。 CPUスロットルカウンターは動作しません。また、メモリの最適ではないプラン/秒も動作しません。

ワークロードグループでは、メモリの許可をデフォルト（25％）を超えて増やし、最大のdop設定で遊んでいます。クエリを逐次実行しない限り、実行時間に変化はありません。ワークロードグループのmaxdopを1（シリアル実行）に変更すると、クエリはキャッシュ内で1回〜3秒で実行されます（デフォルトグループより1秒遅い）。 maxdopの他のすべてのレベルでは、約70および75倍遅くなります）。

サーバー情報：2ソケットx 6コアサーバー。サーバーのMaxDop =4。テストを実行すると、CPUは比較的静止しています（使用率は約12％）。サーバーのメモリが圧迫されていません（24GBボックスで最大6GBまで無料）。

リソースプールの構成

100％最大メモリ

50％CPU（100％に増やしても違いはありません）

75％CPU CAP

ワークロードグループ

MaxDop 0（および0、1、4、7を試しました）

メモリー許可（25％-SQL推奨の最大70％を試しました）

スロットルを実行しているものを絞り込む方法に関するアイデアはありますか？トラブルシューティング用のMicrosoftリンクから明らかなものが見当たらない

http://technet.Microsoft.com/en-us/library/cc627395（v = sql.105）.aspx

デフォルトプール（クイック）実行の完全な計画- http://Pastebin.com/y0P9J61f

ユーザープール（低速）実行の完全な計画- http://Pastebin.com/20hnFSTW

問題のクエリは計画の2番目のステートメントです（最初のステートメントは重要ではなく、とにかく並列実行されません...）

sql-serversql-server-2012resource-governor
5
JorgeSandoval

アップデート-どのタイプのスロットリングが実行されているかを検出する最善の方法はまだわかりませんが、私の場合は原因を特定しました。 CPU CAPを75％にすると、25％の低下が示唆するよりもはるかに高いパフォーマンス低下を引き起こしたようです。 CPUキャップを100％に上げると、問題が解決しました。

接続に関する記事は、これがCPUキャップの実装自体の問題である可能性を検証しているようです。

これはこの質問に対する最良の答えではありません。また、誰かがまだ元の「スロットルが行われていることを確認する方法...」の質問に答えたい場合は、私は従順です。

クエリが非常に深刻に抑制されている理由を理解するのに苦労している場合、これは試してみる価値のある解決策になる可能性があります。

http://connect.Microsoft.com/SQLServer/feedback/details/781335/resource-governor-feature-cap-cpu-percent-does-not-work-as-expected

2
JorgeSandoval