MS SQL Server 2016データベースで速度が低下しているため、Brent Ozarの応急処置キットを使用して初期トラブルシューティングを行っています。
10のCPUで99時間の待機が確認された17.5時間のデータサンプルのうち、55.5%という大量のCXPACKET待機タイプが表示されています。
私はここの誰かがこの数について心配する必要があることを確認し、できるだけ早く解決できることを望んでいました。 MAXDOP設定は4であり、MSの推奨に正確ですが、CTPは5に設定されています。これは、50に変更する必要があると思います。
上司にこの情報を提供する前に、説明を探しているだけです。そうです、私はデータベース管理に不慣れで、他の待機タイプを探していますが、これが今のところ最も重要なようです。
乾杯、
ジョシュ
13.0.1745.2を使用しているとのことですが、これはRTM SQL Serverのバージョンであり、実際には 2018年1月9日の時点でサポート対象外 です。
さらに、SP2をインストールすると、新しいCXCONSUMER待機タイプが表示されます(詳細については こちら を参照してください)。これにより、「無害な」並列処理の待機が、実際に何かを実行できる待機から分離されます。これは、CXPACKETがサーバーに本当に問題があるかどうかを判断するのに役立ちます。
Paul Randalのこの記事をチェックしてください。 Knee-Jerk Wait Statistics:CXPACKET
その中で彼は、CXPACKETがどのように通常の待機タイプになることができるかについて話します-クエリが並列になる場合は常に発生します(特に、CXCONSUMERがまだ分割されていないため)。また、クエリの調整がMAXDOPとコストのしきい値の調整よりも効果的な解決策(根本的な原因を突き止める)になる方法についても説明します。
予期しない並列処理の一般的なケースの1つは、小さいインデックスシークまたはスキャンを期待している場所でテーブルスキャンが発生した場合です。
彼はさらに、インデックス作成、統計の更新などを使用してスキャンを排除できるため、クエリが並列処理される可能性が低くなると述べています。
CXPACKET待機の量を減らす必要がある場合は、MAXDOPを(現在の設定4から)2に減らすことができますが、これにより他の問題が発生する可能性があります。もちろん、すでに4がパフォーマンステストを通じてシステムに適した設定であると判断した場合は、その提案を無視してください。
別のオプションは、この値を増やして、一部のクエリが完全に並列にならないようにすることです。 50がデフォルトのではなく、(== --- ==)から始めるのに適していることを示唆する多くのアドバイスを見てきました5( 例 )。
SQL Serverが実行しているワークロードの種類は、OLTP(並列処理があったとしても、はるかに少ないとメリットがあります)、または非常に重いETLタイプのクエリ(並列処理が有益である場合)です)-現実は両方の混合かもしれません。
並列処理が必要な場合、MAXDOP 4は妥当に聞こえますが、デフォルトのコストしきい値が低すぎるため、5を超えるクエリは並列プランを使用する可能性があるため、変更の候補になることは間違いありません(50が広く評価されている最良の出発点です) )。
ワークロードが理解され、サーバーの並列処理が正しく構成されたら、クエリの分析を開始できます。並列処理が必要なためですか、それともインデックスなどで調整する必要があるためにコストが高くなりますか?