SQL Server で、並列クエリの待ち事象を確認する際には「CXPACKET」「EXECSYNC」「EXCHANGE」を確認するのが一般的でしたが、SQL Server 2017 CU3 では、上記に加えて「CXCONSUMER」という待ち事象が増えています。
これにより、いままで CXPACKET として集計されていた一部の挙動が CXCONSUMER の方に集計されるようになります。
この動作自体は、PASS Summit 2017 で発表が行われ、Making parallelism waits actionable で解説されていたのですが、CU3 がリリースされたことで実際に検証が可能となりました。
今回の機能追加に伴い、sys.dm_os_wait_stats (Transact-SQL) のドキュメントも更新されています。
CXCONSUMER
行を送信する、producer スレッド consumer スレッドが待機したときに、並列クエリ プランで発生します。 これは、並列クエリの実行の通常の一部です。
適用されます: SQL Server 2017 CU3 と SQL データベースCXPACKET
クエリ プロセッサ交換反復子を同期するときに、および生成および行を使用する場合は、並列クエリ プランで発生します。 待機時間が長すぎて、クエリのチューニング (インデックスの追加など) を実行しても短くできない場合は、並列処理のコストしきい値を調整したり並列処理の次数を下げたりすることを検討してください。
注:でSQL Server 2017CU3 および SQL データベース、クエリ プロセッサ交換反復子を同期するように、コンシューマーのスレッドの行を作成できるようにのみ CXPACKET を参照します。 コンシューマーのスレッドは、CXCONSUMER 待機の種類で個別に追跡されます。
検証する際は、次のドキュメントと合わせて確認すると理解しやすいかと。
- CXPACKET 待ちは悪いことか？
- DOPは並列クエリで使用されるスレッド数ではない
- Parallel Query Execution in SQL Server
- Understanding and Controlling Parallel Query Processing in SQL Server
手元の SCVMM 用の DB で並列クエリが実行されているものがあったので、これを使いながら軽く検証を。
Read the rest of this entry »