web-dev-qa-db-ja.com

Parallelism Exchangeイベントのデッドロックが被害者なしである場合、それは問題ですか？

これらの多くは Intra-Query Parallel Thread Deadlocks が本番環境（SQL Server 2012 SP2-はい...わかっています...）で見られますが、デッドロックXMLを見ると、拡張イベントを介してキャプチャされているため、犠牲者リストは空です。

<victim-list />

デッドロックは4つのスレッドの間にあり、2つはWaitType="e_waitPipeNewRow"と2つのWaitType="e_waitPipeGetRow"。

 <resource-list>
  <exchangeEvent id="Pipe13904cb620" WaitType="e_waitPipeNewRow" nodeId="19">
   <owner-list>
    <owner id="process4649868" />
   </owner-list>
   <waiter-list>
    <waiter id="process40eb498" />
   </waiter-list>
  </exchangeEvent>
  <exchangeEvent id="Pipe30670d480" WaitType="e_waitPipeNewRow" nodeId="21">
   <owner-list>
    <owner id="process368ecf8" />
   </owner-list>
   <waiter-list>
    <waiter id="process46a0cf8" />
   </waiter-list>
  </exchangeEvent>
  <exchangeEvent id="Pipe13904cb4e0" WaitType="e_waitPipeGetRow" nodeId="19">
   <owner-list>
    <owner id="process40eb498" />
   </owner-list>
   <waiter-list>
    <waiter id="process368ecf8" />
   </waiter-list>
  </exchangeEvent>
  <exchangeEvent id="Pipe4a106e060" WaitType="e_waitPipeGetRow" nodeId="21">
   <owner-list>
    <owner id="process46a0cf8" />
   </owner-list>
   <waiter-list>
    <waiter id="process4649868" />
   </waiter-list>
  </exchangeEvent>
 </resource-list>

そう：

  1. 犠牲者リストは空です
  2. クエリを実行するアプリケーションはエラーにならず、クエリを完了します
  3. 私たちが見る限り、グラフがキャプチャされていること以外は明らかな問題はありません

だから、ノイズ以外に気になることはありますか？

編集：Paulの回答のおかげで、問題が発生する可能性が高い場所を確認でき、tempdbの流出により問題が解決したようです。 enter image description here

sql-serverdeadlockparallelism
10
Mark Sinkinson

これがクエリ内並列のデッドロックがエクスチェンジのスピルによって解決されたときのデッドロックグラフの見え方であるとしても、驚かないでしょう（パフォーマンス以外には犠牲者はありません）。

この理論を確認するには、交換の流出をキャプチャし、デッドロックに一致させる（または一致させない）ことができます。

デッドロックを解決するために交換バッファーをtempdbに書き込むことは理想的ではありません。実行計画の順序を維持する操作のシーケンスを排除するようにしてください（例：並列マージ結合を供給する順序を維持する交換）。それが顕著なパフォーマンスの問題を引き起こしていない限り、そしてあなたが他に心配しなければならないことがあります。

興味深いことに、この問題は、高度な断片化/古い統計によって悪化する可能性がありますか？

断片化、いいえ。時代遅れの統計：私が考えることができる特定の意味ではありません、いいえ。もちろん、代表的でない統計が一般的に良いことであることはめったにありません。

ここでの基本的な問題は、スレッド間の依存関係ができるだけ少ないときに並列処理が最もうまく機能することです。保存された順序は、かなり厄介な依存関係をもたらします。物事は簡単に混乱する可能性があり、ログジャムをクリアする唯一の方法は、取引所で保持されている行の束をtempdbに流すことです。

11
Paul White 9