web-dev-qa-db-fra.com

Si un blocage d'événement d'échange de parallélisme est sans victime, est-ce un problème?

Nous en voyons beaucoup Intl-Query Parallel Thread Deadlocks dans notre environnement de production (SQL Server 2012 SP2 - oui ... je sais ...), cependant quand on regarde le Deadlock XML qui a été capturée via des événements étendus, la liste des victimes est vide.

<victim-list />

Le blocage semble être entre 4 threads, deux avec le WaitType="e_waitPipeNewRow" et deux avec le 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>

Donc:

  1. La liste des victimes est vide
  2. L'application exécutant la requête ne génère pas d'erreur et termine la requête
  3. Pour autant que nous puissions voir, il n'y a pas de problème évident, à part que le graphique est capturé

Par conséquent, est-ce quelque chose à craindre autre que le bruit?

Edit: Grâce à la réponse de Paul, je peux voir où le problème se produit et semble se résoudre avec le déversement tempdb. enter image description here

sql-serverdeadlockparallelism
10
Mark Sinkinson

Je ne serais pas surpris si c'est à cela que ressemble le graphique de blocage lorsqu'un blocage parallèle intra-requête est résolu par un déversement d'échange (donc il n'y a pas de victime, sauf les performances).

Vous pouvez confirmer cette théorie en capturant les déversements d'échange et en les faisant correspondre (ou non) à l'impasse.

L'écriture de tampons d'échange dans tempdb pour résoudre un blocage n'est pas idéale. Essayez d'éliminer les séquences d'opérations préservant l'ordre dans le plan d'exécution (par exemple, les échanges préservant l'ordre alimentant une jointure de fusion parallèle). À moins que cela ne cause pas de problème de performance notable et que vous ayez d'autres choses à vous soucier.

Par intérêt, ce problème est-il susceptible d'être exacerbé par une forte fragmentation/des statistiques obsolètes?

Fragmentation, non. Statistiques obsolètes: pas dans un sens spécifique auquel je pense, non. Bien sûr, les statistiques non représentatives sont rarement une bonne chose en général.

Le problème fondamental ici est que le parallélisme fonctionne mieux quand il y a aussi peu de dépendances entre les threads que possible; l'ordre ordonné introduit des dépendances plutôt désagréables. Les choses peuvent facilement être gommées, et la seule façon d'effacer le blocage est de renverser un tas de lignes tenues lors des échanges pour tempdb.

11
Paul White 9