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 :

Requête qui ne parallélise pas en Production [2008R2]


Sujet :

Administration SQL Server

  1. #1
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut Requête qui ne parallélise pas en Production
    Bonjour a tous,

    Je me trouve confronter a un problème assez perturbant.
    Lorsque je me suis lancé dans l’étude d’un problème de performance remonté ce matin par les utilisateurs sur une application j’ai constaté un phénomène assez surprenant : la requête directement impliqué dans cette chute de performance (conséquente) ne parallélise pas sur mon environnement de production alors qu’elle parallélise parfaitement dans l’environnement de pré-Production.
    Afin d’évacuer toute fausse piste je précise les éléments suivants :

    L’environnement de Pré-Production et l’environnement de Production sont d’un point de vu machine physique les mêmes pour ce qui est des disques et de la CPU, le serveur de production a été gonflé en RAM (24Go en Production, 16Go en Pré-Production).
    La base de données de l’environnement de pré-Production est une restauration de la base de production datant de moins d’un mois.
    La reconstruction des indexes et la mise à jours des statistiques sont effectuer sur cette base chaque soir dans les 2 environnements et se sont correctement effectué la nuit dernière.
    Enfin les plan d’exécution de la requête récupérés sur les 2 environnements sont les mêmes, au parallélisme prêt, avec des couts très similaires aux même étapes (comparaison effectué avec SQL Sentry Plan Explorer).
    Fort de ces éléments j’ai évidement immédiatement comparé les paramètres de parallélisassions des requêtes pour les instances, la seule différence entre les 2 était le MAXDOP, a 0 sur le serveur de Pré-Production et a 16 (le nombre de cœurs de CPU pour la machine) sur le serveur de Production. Histoire d’être totalement cohérent j’ai positionné le MAXDOP à 16 sur le serveur de Pré-Production.
    Le comportement est toujours le même.

    J’ai bien évidement chercher sur le net, dans les msdn et autres blog des informations concernant le choix ou non par le moteur d’utiliser la parallélisassions pour les requêtes et il me semble qu’aucun facteur empêchant son utilisation ne soit a l’œuvre sur mon serveur de production.

    Je suis donc perplexe et mes utilisateurs sont agacés (il semble que le problème ne survienne que depuis ce matin ce qui indiquerais que jusqu'à vendredi au moins le moteur parallélisait correctement la requête) par un temps de réponse fortement dégradé (2 secondes en Pré-Production pour rendre prêt de 23000 lignes, plus de 4 minutes en Production pour rendre prêt de 5000 lignes, interrompu avant la fin puisque requête trop lente et trop pénalisante pour les autres utilisateurs).

    Merci de toute l’aide que vous pourrez m’apporter dans ma recherche d’explication et de solution.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 897
    Points : 53 135
    Points
    53 135
    Billets dans le blog
    6
    Par défaut
    Quelle version/edition de SQL Server ?
    Quel OS ?
    Quelle config machine au niveau CPU core threading ?
    Quel config au niveau des IO affinity ?
    Utilisez vous le gouverneur de ressources ?

    A +

  3. #3
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    - Version de SQL Serveur : 10.50.1600 Standard x64 des 2 cotés
    - Version OS Windows 2003 R2 SP2 Standard x64 pour les 2 environnements
    - Ou puis je trouver cette information ?
    - I/O affinity par defaut en automatique
    - Pas de gouverneur de ressource.

    Merci et A+

  4. #4
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Points : 12 891
    Points
    12 891
    Par défaut
    Est-ce que les paramètres de configuration de niveau serveur "max degree of parallelism" et "cost threshold for parallelism" ont une valeur particulière sur l'environnement de production par rapport à celui de préprod ?

    ++

  5. #5
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

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

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    J'ajouterais que passer de 2 secondes à 4 minutes ne s'expliquent surement pas que par l'absence de parallelisation en production...

    Voyez votre plan d’exécution, bien d'autres choses peuvent expliquer cette accroissement de temps de réponse (soudaine augmentation du volume de données par exemple...)
    Avez vous par exemple tenté en pre-production de bloquer la parallelisation (MAX DOP 1) et comparer les temps?

  6. #6
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Comme je l'ai expliquer la configuration de niveau serveur "max degree of parallelism" et "cost threshold for parallelism" sont identiques dans les 2 environnement et les plan d'execution sont les memes a la seule difference du paralellisme.

    Il n'y a pas non plus d'accroissement de volume démesuré entre les 2 environnement (l'estimated Row en Pré-Prodution est de 50000 ligne, en production de 75000 lignes avec des statistiques a jours dans les 2 environnements).

    Je vais effectuer le test en Pré-Production avec le Maxdop a 1 et revenir vers vous.

  7. #7
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Prise de mesure de ce matin
    Pré-Prod avec MAXDOP 1 : 29 Seconde pour 23000 lignes retournées
    Prod avec MAXDOP 1 : 50 seconde pour 45000 lignes retournées (idem sans option maxdop et sans effet de cache, 8 seconde avec l'effet de cache)

    Ca n'explique pas les temps d'hier (je ne connais pas les conditions de la prise de mesure car je ne l'ai pas effectué moi meme c'est le temps annoncé par un utilisateur).

    j'ajoute que sans option maxdop dans la requete l'environnement de Pré-Production active correctement le paralellisme alors que l'environnement de production ne le fait pas.

  8. #8
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

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

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    j'ajoute que sans option maxdop dans la requête l'environnement de Pré-Production active correctement le paralellisme alors que l'environnement de production ne le fait pas.
    Il n'y a pas d'activation "correcte" de la parallelisation!

    SQL SERVER détermine lui même au moment de l’exécution, en fonction du plan d’exécution mais aussi et surtout de la charge actuelle du serveur s'il peut paralleliser:
    Vais-je gagner du temps?
    Est-il pertinent de solliciter plusieurs processeur/cœur alors que la charge CPU est actuellement importante?

    Et en PRODUCTION les gens bossent... pas en PREPROD en général.

  9. #9
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Certes, je précise donc que le serveur n'etant pas en France, les horaires ou j'ai fais mes tests ne correspondaient pas aux horaires d'activités du serveur et donc le serveur n'est pas sollicité.

  10. #10
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

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

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Clairement vous manquez d'infos:
    "temps annoncé par un utilisateur"

    Ça c'est un ressenti devant son écran, nullement une mesure sérieuse prise avec les outils adéquat...

  11. #11
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Je suis en train d'essayer de joindre celui qui a "pris la mesure" pour connaitre les conditions exactes.

    Reste que le temps de reponse en Pré-Production est degrader (de 2 a 29 secondes) avec un maxdop a 1, que le serveur de production ne paralellise pas (l'objet de ma question est pourquoi, quelles sont les causes de ce choix du moteur alors qu'a mon sens aucune des conditions ne sont réunie pour qu'il ne parallelise pas).
    Dans les infos disponible j'ai le fait que le degré de parallelisation retenu par SQL en Pré-Production est de 4 et que les 2 serveurs disposent chacun de 16 coeurs de CPU.

  12. #12
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Mon utilisateurs vient de me confirmer que ses temps sont fantaisistes puisque mesuré sur un management studio en France alors que le serveur est dans les iles ...

    Les vrais bon temps sont donc ceux que j'ai pu mesuré et annoncer ci dessus.

  13. #13
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Ok je nage dans la perplexité avec un nouveau test que je viens d'effectuer.

    A priori c'est le serveur de Production qui a raison...

    Test effectué en Pré-Production :
    DBCC DROPCLEANBUFFERS
    DBCC FREEPROCCACHE

    <ma requete>
    option (MAXDOP 16)

    ==> 23000 lignes retournées en 50 secondes

    DBCC DROPCLEANBUFFERS
    DBCC FREEPROCCACHE

    <ma requete>
    option (MAXDOP 1)

    ==> 23000 lignes retournées en 40 secondes

    La baisse de performance constatée en production semblerait donc plutot provenir d'un renouvellement du cache de donnée plus important en Production qu'en Pré-Production ce qui est pour le coup tout a fait normal (il n'y a pas de contention mémoire toutefois, ces juste que ces données sont très changeantes).

  14. #14
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

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

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Ok

    Malgré tout ce temps vous parait-il normal et satisfaisant compte tenu du travail effectué par la requête?

  15. #15
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Non absolument pas, mais on entre dans un autre debat et la c'est le petit musé des horreur d'un progiciel pour lequel nous n'avons pas la main sur le code :
    - Base non normalisé (certaines tables ne respecte meme pas la premiere forme normale)
    - Base non purgée (plus de 5 ans d'historique non archivé et purgé)
    - Plan d'indexation fait en depit du bon sens et non modifié par l'editeur malgre mes remarques et insistances répétées.

    Bref je vais clore ce sujet qui deviendrait si on allais plus avant dans le code en "tout ce qu'il ne faut absolument pas faire en terme de devellopement".

    Merci de votre aide en tout cas car toutes vos remarques m'ont permis d'orianté mes tests et mon investigation de facon a produire au service d'etude une reponse claire et précise sur l'explication des temps de reponses.

    Bonne journée a vous.

  16. #16
    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 : 43
    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,

    Comme vous dites que c'est un progiciel, et donc vous ne pouvez pas faire grand chose. C'est dommage de ne pas aller jusqu'au boulot de cette analyse pour comprendre ce que fait l'optimiseur.

    Je vous propose donc de regarder si les options de configuration affinity mask et affinity64 mask sont identiques, car cela peut aussi influencer l'optimiseur.

    S'ils sont identiques, ce qui est fort probablement le cas, il serait intéressant de comparer les statistiques, car il doit bien y avoir quelque chose qui fait que l'optimiseur n'a pas le même comportement. J'ai déjà observé cela sur des éditions différentes de la même version de SQL Server, mais pas sur des versions identiques ...

    Avez-vous réalisé une comparaison des documents XML que sont les plans de requêtes avec un logiciel comme WinMerge ou Beyond Compare ? Cela aiderait peut-être à trouver où est véritablement la différence

    D'autre part, on voit que vous êtes en SQL Server 2008 R2 RTM. Est-ce que l'éditeur du progiciel vous empêche / ne supporte pas le SP1 ou 2 ?

    @++

  17. #17
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Points : 12 891
    Points
    12 891
    Par défaut
    Comme Elsuket je dirais que si aucun facteur de configuration n'est en cause, je serais curieux de voir les cardinalités estimés sur les 2 environnements

    ++

  18. #18
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Merci a vous car le sujet m'intrigue egalement.

    Pour ce qui est des cardinalités en jeux je les ai donnés plus haut, je les redonne ici :
    l'estimated Row en Pré-Prodution est (a la louche) de 50000 ligne, en production de 75000 lignes avec des statistiques a jours dans les 2 environnements.

    Pour ce qui est des affinity mask :
    En Pré-Prod
    1549 affinity64 mask 0 -2147483648 2147483647 0
    1551 affinity64 I/O mask 0 -2147483648 2147483647 0
    1535 affinity mask 0 -2147483648 2147483647 0
    1550 affinity I/O mask 0 -2147483648 2147483647 0

    En Prod
    1549 affinity64 mask 0 -2147483648 2147483647 0
    1551 affinity64 I/O mask 0 -2147483648 2147483647 0
    1535 affinity mask 0 -2147483648 2147483647 0
    1550 affinity I/O mask 0 -2147483648 2147483647 0

    la meme chose donc ==> configuration par defaut auto géré par SQL Server

    La comparaison des plans XML a été faite avec SQL Sentry Plan Explorer (si vous connaissez pas je vous invite a y jeter un oeil, personnellement j'ai beaucoup aimer).

    J'ai essayer de vous mettre les 2 XML en pj dans le poste
    Fichiers attachés Fichiers attachés

  19. #19
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    43
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : Juillet 2009
    Messages : 43
    Points : 22
    Points
    22
    Par défaut
    Pour ce qui est de patcher le SQL ce n'est pas un blocage de l'editeur mais contextuel.
    Au lieu de patcher tous les serveur (en france et dans les DOM-TOM) concernant cette application nous avons pris le parti de centraliser l'application et l'operation est en cours (sur un serveur windows 2008 R2 et avec un SQL 2008 R2 SP3 cette fois). Il n'a pas été souhaiter de mettre a jour des environnement tres prochainement obsolete.

  20. #20
    Membre éprouvé
    Profil pro
    Inscrit en
    Février 2008
    Messages
    758
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 758
    Points : 1 069
    Points
    1 069
    Par défaut
    Hello,

    Est-ce possible de poster un set statistics profile on dans les deux environnements et joindre le tout dans un fichier texte ? Avec la requête ?

    --

    Je retire, je viens de voir les plans XML

    Merci

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Requête qui ne sélectionne pas tout
    Par Miss Ti dans le forum Requêtes et SQL.
    Réponses: 13
    Dernier message: 25/07/2006, 15h18
  2. Réponses: 8
    Dernier message: 26/01/2006, 14h47
  3. [php-mysql] requête qui ne marche pas....
    Par sanosuke85 dans le forum Requêtes
    Réponses: 1
    Dernier message: 09/01/2006, 17h18
  4. Une requête qui ne reconnait pas is not null
    Par LeBauw dans le forum Access
    Réponses: 2
    Dernier message: 08/09/2005, 12h29
  5. Requête qui ne passe pas
    Par TheBart dans le forum Langage SQL
    Réponses: 2
    Dernier message: 10/08/2005, 10h12

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