web-dev-qa-db-ja.com

巨大なCXPACKETとLATCH_EX（ACCESS_METHODS_DATASET_PARENT）の待ち時間を減らす方法は？

問題

年初から、システム全体でのSQLタイムアウトが原因で、ユーザーの混乱が高水準で発生しています。

問題のSQL-Serverインスタンスは、営業時間中に非常に高いCPU使用率（常にすべての16コアで90％を超える）を持っています。

また、待機時間が非常に長いことにも気づきました。CXPACKETとLATCH_EXの組み合わせが、すべての待機の約97％を占めています。これは、CXPACKETとLATCH_EXの間で約50/50に分割されます。

LATCH_EXの大部分（> 95％）を占める非バッファラッチ待機は、ACCESS_METHODS_DATASET_PARENTです。

これは、問題が並列処理に関係していることを示唆しています。

待機時間のスケールの例は次のとおりです。

_CXPACKET : 332,301,799 ms
LATCH_EX : 267,955,752 ms
PAGEIOLATCH_SH : 2,955,160 ms
_

これは、1月11日の08：00-16：24の間の期間でした。

検討中のオプション

1）MAXDOPを0から4から8の間の値に変更します

2）並列処理のコストしきい値を50からより高い数値に変更します。

私たちが直面している非常に高いCPU負荷を緩和し、タイムアウトを削減する方法、特に提案された一連のアクションが賢明かどうか、MAXDOPと並列処理のコストしきい値をどの数値に変更するかについての提案は最も歓迎されます。

背景情報

  • AMD Opteron 6180 SEで実行されているSQL-Server 2008 R2。そのうち16コアがSQL-Serverのこのインスタンスに割り当てられています。

  • ワークロードのタイプ：営業時間中に同時に800接続程度のオーダー。過半数OLTP一部のOLAPが混在するタイプのワークロード.

  • Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) ... Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1).メモリは24コア間で約128ギガです。このインスタンスでは16個のコアを使用できます

sql-server-2008-r2parallelismtimeoutmaxdoplatch
5
matskm

過半数OLTP一部のOLAPが混在するワークロード

これは問題であり、CXPACKETではありません。並列処理は症状であり、原因ではありません。あなたの '一部' OLAPワークロードはスキャンを実行して並列処理をトリガーします。これは、交換待ち時間にカスケードし、バッファプールの汚染とブロックの可能性があります（OLTPワークロードはOLAP =スキャン）。

OLAPワークロードがよく理解されており、絶対に重要である場合は、そのための適切なカバリングインデックスを追加することを検討できます。しかし、これは常に困難な戦いです。OLAPワークロードは、有害なスキャンとともに専用のボックスに移動します。新しいバージョン（SQL Server 2014）には、読み取り可能なセカンダリと列ストアがあり、どちらも分析/アドホック/ OLAPワークロードの提供に優れています。

SQL Server 2008 R2の場合は、ログ配布またはレプリケーションを検討します（ただし、「完璧」なものはないと思います）。

短期：パフォーマンスの問題があり、適切に分析する必要があります。 SQL Serverパフォーマンスの分析方法 をお読みください。 Identifyほとんどの損傷を引き起こすクエリ（ 問題のクエリの特定 を参照）。実際の問題を特定した後にのみ、ソリューションを推奨できますか。

注意：LATCH_EX オン ACCESS_METHODS_DATASET_PARENTは、約IO=についてではありません。並列処理に厳密に関連しており、並列スキャンの「子」スレッドが親スレッドで取得して、その子にスキャン範囲を割り当てる必要があるラッチと同様です。 。競合は、並列処理が非効率的であることを示します（実際の有用な作業よりも「宿題」を行っています）。パーティション化により、この症状、特に整列されていないパーティション化が悪化します（パーティションごとに親/子データセットが設定されているため） ）カーディナリティの推定値が悪い（統計が古い）ことも原因である可能性があり、必要でない場合は並列処理を行います。オンと私のアドバイスはすべて同じです。実際の問題のクエリを特定します。

7
Remus Rusanu

前述のように、CXPACKETは多くの場合、高い値が必ずしも悪いわけではないという意味で誤解を招く待機タイプであり、非常に多くの場合、これらの高い値は単なる指標であり、実際の問題ではありません。

したがって、CXPACKEDに付随する他の待機タイプを調べることは、トラブルシューティングの出発点として適しています。以下を確認することをお勧めします。

  • 並列処理のコストしきい値（CTFP）を確認し、使用する値がシステムに適切であることを確認してください

  • CXPACKETにLATCH_XXが付いているかどうかを確認します（場合によっては、PAGEIOLATCH_XX、またはSOS_SCHEDULER_YIELDも付いている可能性があります）。その場合は、ハードウェアに合わせてMAXDOP値を下げる必要があります。

  • CXPACKETにLCK_M_XX（通常はIO_COMPLETIONおよびASYNC_IO_COMPLETIONが付属）が付いているかどうかを確認します。これが事実である場合、並列処理はボトルネックではありません。問題と解決策の根本的な原因を見つけるには、これらの待機統計をトラブルシューティングする必要があります

最後に、 SQL ServerでのCXPACKET待機タイプのトラブルシューティング の記事を読んで、これに関する詳細情報を取得し、最も一般的なシナリオが実際のシナリオであるかどうかを確認してください。

5
Mspaja

remusが言うように、パフォーマンスの問題があります。おそらく、ワークロードが混合していて、SQLステートメントのチューニングが不十分なためです。私の経験では、解決する最良の方法は、SQLクエリでパフォーマンス/チューニングアプローチを使用することです。これが不可能な場合、または重大な状況を管理する必要がある場合は、MAXDOPパラメーターの上限値を下げることができます。より良い値を見つけるには、maxdopクエリintを使用して、報告したイベント（特にLATCH_EX）の上位N sqlクエリを実行できます。

SELECT *
FROM Sales.SalesOrderDetail
ORDER BY ProductID
OPTION (MAXDOP 1)

MAXDOP = 8から開始して、実行時間が減少するか変化しないまで値を下げることができます（そうです、実行時間は減少するか、同じままです）。最適な値を見つけたら、インスタンスレベルで設定します。私の経験では、このアプローチが役立ちますが、覚えておいてください。これは回避策であり、パフォーマンスの問題の解決策ではありません。

1
Giova