Exploitation SQL Server

MAXDOP et seuil de coût du parallélisme

Les valeurs par défaut reflètent rarement une conception volontaire. Trop de parallélisme augmente la pression CPU et workers, tandis qu'une restriction excessive ralentit l'analytique.

MAXDOP et seuil de coût du parallélisme

Les valeurs par défaut reflètent rarement une conception volontaire. Trop de parallélisme augmente la pression CPU et workers, tandis qu'une restriction excessive ralentit l'analytique.

Ce qu'il faut mesurer

Examinez CPU, tâches exécutables, épuisement des workers, durée, plans parallèles, attentes d'échange, NUMA et mélange OLTP et reporting.

Approche pratique

Choisissez un MAXDOP initial selon topologie et charge, augmentez progressivement le seuil de coût, mesurez latence extrême et débit, et réservez les exceptions aux cas démontrés.

Ce qu'il faut éviter

Ne considérez pas CXPACKET comme une preuve, ne fixez pas MAXDOP à un partout et ne changez pas les deux valeurs sans référence.

Résultat opérationnel

Le réglage réussit lorsque débit et latence extrême progressent ensemble, pas lorsqu'une attente disparaît.

Checklist de production

Établissez une référence et définissez l'amélioration attendue. Testez avec des données et une concurrence représentatives. Conservez la configuration ou le plan d'origine, préparez un retour arrière et surveillez le prochain pic normal de charge.

Pour appliquer cette méthode à un environnement SQL Server précis, utilisez le formulaire ci-dessous et indiquez la version, la taille de la base, le profil de charge et les éléments déjà collectés.

Question sur cet article

Vous avez une question sur ce sujet ?

Expliquez ce que vous évaluez ou le point qui vous bloque. Nous vous répondrons avec une recommandation pratique.

Inquiries are not enabled in this preview.

Poser une question sur cet article