IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Deadlock liés à la gestion des processeurs [2008R2]


Sujet :

Administration SQL Server

  1. #1
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut Deadlock liés à la gestion des processeurs
    Bonjour,
    je suis Arrivé chez un client qui "avait des soucis" avec sa base sql server. sa base étant son core business, il fallait agir dans l'urgence.
    Nous sommes dans un contexte de database miroring avec témoin. pour faire simple je ne vous parle que du principal(pour l'instant).
    Le serveur possède 2 instances.une avec la base qui nous intéresse l'autre avec les bases "B.I.". nous avons également sur ce serveur SSRS, SSIS, SSAS...
    pour le même prix on avait en plus un serveur applicatif mais non il se sont arrêté là
    on a 32 coeurs(à priori 2 cpu 8 coeur avec de l'hyperthreading --> point encore à éclaircir)

    l'instance 1 avait un parallélisme de 4 et l'instance 2 de 16
    Là je suis de mémoire mais je pense que 16 (j'ai même une crainte que ce soit 24 mais là je pense que ca aurait même pas fonctionné du tout)?) coeurs étaient attribués à l'instance 1 et 8 à l'autre pour le processor affinity.
    Pour le 8 je suis sur et ca c'est "rigolo" vu le parallelisme à 16
    Le i/o affinity était en automatique.

    En gros on m'a appelé parce que la base "avait des lenteurs" et basculait régulièrement sur la base secondaire.
    Quand je suis arrivé la base plantait complètement 4 à 5 fois par jours.

    en Activant les TFlag 1204 et 1222 j'ai obtenu des chieries de deadlock dans l'error log


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    2016-05-23 12:24:46.40 spid9s      Node:1
     
    2016-05-23 12:24:46.40 spid9s      Port: 0x0000000125288910  Xid Slot: 4, Wait Slot: 1, Task: 0x000000000B341B88, (Producer), Exchange Wait Type: e_waitPipeNewRow, Merging: 1
    2016-05-23 12:24:46.40 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:20 TaskProxy:(0x00000000B8631DE0) Value:0xb341b88 Cost:(20/0)
    2016-05-23 12:24:46.40 spid9s      
    2016-05-23 12:24:46.40 spid9s      Node:2
     
    2016-05-23 12:24:46.40 spid9s      Port: 0x00000001155B4A60  Xid Slot: 4, Wait Slot: 2, Task: 0x000000000B4874C8, (Producer), Exchange Wait Type: e_waitPipeNewRow, Merging: 1
    2016-05-23 12:24:46.40 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:15 TaskProxy:(0x00000000B8631C00) Value:0xb4874c8 Cost:(20/0)
    2016-05-23 12:24:46.40 spid9s      
    2016-05-23 12:24:46.40 spid9s      Node:3
     
    2016-05-23 12:24:46.41 spid9s      Port: 0x00000001263C8AB0  Xid Slot: 5, Wait Slot: 1, Task: 0x000000000B487288, (Producer), Exchange Wait Type: e_waitPipeNewRow, Merging: 1
    2016-05-23 12:24:46.41 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:17 TaskProxy:(0x00000000B8631CC0) Value:0xb487288 Cost:(20/0)
    2016-05-23 12:24:46.41 spid9s      
    2016-05-23 12:24:46.41 spid9s      Node:4
     
    2016-05-23 12:24:46.41 spid9s      Port: 0x00000001261F8530  Xid Slot: 7, Wait Slot: 1, Task: 0x000000000B8BE088, (Producer), Exchange Wait Type: e_waitPipeNewRow, Merging: 1
    2016-05-23 12:24:46.41 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:19 TaskProxy:(0x00000000B8631D80) Value:0xb8be088 Cost:(20/0)
    2016-05-23 12:24:46.41 spid9s      
    2016-05-23 12:24:46.41 spid9s      Node:5
     
    2016-05-23 12:24:46.41 spid9s      Port: 0x00000001263C9730  Xid Slot: 6, Wait Slot: 1, Task: 0x000000000B345288, (Producer), Exchange Wait Type: e_waitPipeNewRow, Merging: 0
    2016-05-23 12:24:46.41 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:18 TaskProxy:(0x00000000B8631D20) Value:0xb345288 Cost:(0/10000)
    2016-05-23 12:24:46.41 spid9s      
    2016-05-23 12:24:46.41 spid9s      Node:6
     
    2016-05-23 12:24:46.41 spid9s      Port: 0x000000008034B900  Xid Slot: 2, Wait Slot: -1, Task: 0x000000000B345708, (Consumer), Exchange Wait Type: e_waitPortClose, Merging: 0
    2016-05-23 12:24:46.41 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:8 TaskProxy:(0x00000000B8631960) Value:0xb345708 Cost:(0/10000)
    2016-05-23 12:24:46.41 spid9s      
    2016-05-23 12:24:46.41 spid9s      Node:7
     
    2016-05-23 12:24:46.41 spid9s      Port: 0x0000000126214360  Xid Slot: 1, Wait Slot: 4, Task: 0x000000000B487708, (Consumer), Exchange Wait Type: e_waitPipeGetRow, Merging: 0
    2016-05-23 12:24:46.41 spid9s       ResType:ExchangeId Stype:'AND' SPID:455 BatchID:0 ECID:6 TaskProxy:(0x00000000B86318A0) Value:0xb487708 Cost:(0/10000)
    2016-05-23 12:24:48.93 spid9s      Deadlock encountered .... Printing deadlock information
    2016-05-23 12:24:48.93 spid9s      Wait-for graph
    2016-05-23 12:24:48.93 spid9s
    ce qui est "amusant" c'est que le sql profiler ne chopait pas ces deadlock là (mais bien d'autres)

    J'ai remis "un peu" d'ordre de manière générale. et vu le bordel et qu'on ne savait pas m'expliqué ce qui avait amené à une telle configuration. j'ai mis le parallélisme à 1 et remis l'affinity processor en automatique.
    aujourd'hui, plus de plantage et plus ces affreux deadlock (y en a toujours d'autres mais ceux là je les comprend)

    J'ai été un peu long pour vous remettre dans le contexte mais je voudrais avoir votre avis sur ce qui peut provoquer ce genre de deadlock et surtout avoir votre éclairage sur la lecture de ce log

    Merci d'avance
    Cordialement

    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  2. #2
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Bonjour,

    Tout d'abord une petite correction sur le titre de la discussion que vous avez ouverte : les deadlocks ne sont pas directement liés à la gestion que fait SQL Server de l'attribution d'un thread d'une requête parallélisée à un core ou CPU. L'exemple de deadlock que vous donnez se produit lorsque :

    • un thread A détient une ressource sur l'objet X et attend une ressource sur l'objet Y
    • un thread B détient une ressource sur l'objet Y et attend une ressource sur l'objet X


    Cet exemple est basé sur deux threads participant à l'exécution parallélisée d'une requête, mais il peut bien sûr y en avoir davantage, comme le montre d'ailleurs votre exemple.

    Supposons que la requête a un degré de parallélisation de 4. Il y aura donc :

    • 4 threads "producteurs" qui accéderont aux données
    • 4 threads "consommateurs" qui traiteront ces données
    • 1 thread de contrôle de ces 4 + 4 threads.


    Dès lors il est possible que les threads consommateurs soient en attente de données à traiter des threads producteurs, et inversement : les threads producteurs peuvent avoir à attendre que les threads consommateurs aient terminé de traiter les données.

    Pour éliminer un tel type de deadlock, il convient comme bien souvent pour un problème de performance, de s'en remettre à l'analyse du plan d'exécution de la requête :
    • Quel est le coût de la requête ? est-il bien au dessus de la valeur de l'option de configuration de seuil de coût pour parallélisation ?
    • L'exécution parallélisée est-elle justifiée ? En d'autres termes, est-ce que le simple ajout d'un index ne permettrait pas de diminuer, voire d'éliminer cette parallélisation ?
    • L'expression de la requête n'induit-elle pas cette parallélisation (transtypages implicites par exemple, ...)


    Désactiver la parallélisation est le remède de cheval, puisque comme je vous l'ai exposé dans une autre discussion, d'autres requêtes peuvent en bénéficier.
    On peut alternativement choisir de désactiver la parallélisation de la requête à l'aide de l'indicateur OPTION (MAXDOP 1) si c'est justifié, ou bien élever la valeur de l'option de configuration de seuil de coût pour parallélisation de 5 à 50 ou plus, et placer celle de degré maximal de parallélisation au nombre de cores n'excédant toutefois pas 8.

    Cette dernière recommandation provient de ma propre expérience et n'engage donc que moi
    Le plus fin est d'étudier le cache de plans pour ce faire, à l'aide du coût médian des requêtes, en divisant éventuellement l'ensemble entre requêtes sérialisées et requêtes parallélisées.

    @++

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Gestion des objets liés à un element du DOM
    Par RapotOR dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 07/02/2010, 14h28
  2. [Gestion des Processeurs] Processeurs sous cadences
    Par mavina dans le forum Windows XP
    Réponses: 6
    Dernier message: 10/12/2008, 13h40
  3. Gestion des processeur centrino sous Vista
    Par SkiZoSnaKe dans le forum Windows Vista
    Réponses: 2
    Dernier message: 23/04/2007, 14h03
  4. Gestion des ressources processeur
    Par poussinphp dans le forum SDL
    Réponses: 5
    Dernier message: 30/05/2006, 16h42
  5. Gestion des interruptions du µProcesseur
    Par herve13 dans le forum Assembleur
    Réponses: 3
    Dernier message: 22/08/2005, 21h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo