Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQL Server : Votre serveur consomme trop de processeur, pourquoi ?

Un serveur de base de données est consommateur par essence de ressources CPU. Mais contrairement à ce que pense beaucoup de personne ce n'est généralement pas la principale ressource dont il a besoin.

A savoir que la gestion de l'exécution des requêtes par SQL Server ne suit pas le modèle de Windows. Le multitâche préemptif n'est pas le modèle idéal pour SQL Server, il lui préfère le multitâche coopératif entre ses threads. Pour cette raison le multi cœur / processeur est quasi une obligation sur ce type de serveur de base de données, mais au-delà il faut en voir les besoins.

Pour contrôler la charge processeur et les attentes liées à celle ci je vous invite à jeter un œil ici :
http://blogs.codes-sources.com/christian/archive/2007/01/11/sql-server-votre-serveur-a-t-il-un-probl-me-de-cpu.aspx

Quelles sont les principales raison d'une consommation excessive de CPU ?

Les Compilations et Recompilations

Toute requête doit être compilée en vue de son exécution. Cette phase assimilable à un algorithme de recherche de la meilleure stratégie comme dans un jeu vidéo, permet de trouver le mode d'exécution optimal de la requête. C'est une opération qui est typiquement consommatrice de processeur, et peuvent être aisément être évitées sur les requêtes exécutées fréquemment. Une requête exécutant un million d'insertion dans une table par jour est candidate à ce genre d'optimisation.

On les évite en :

==> utilisant des procédures stockées ou des requêtes paramétrées (sp_executesql et sqlCommand avec SqlParameters en Ado.net). Attention l'utilisation des ces derniers à aussi des effets pervers, comme de fausser l'exécution des requêtes lorsque que les paramètres changent beaucoup.

Les Requêtes de texte intégral

C'est une recherche qui utilise un index composé des mots extraits du texte recherché. Se rajoute à cela des règles spécifiques aux langues pour améliorer la recherche. Le principe est dès lors le même qu'un moteur de recherche type live ou google. La construction de l'index est une opération couteuse en processeur, ainsi que les requêtes quand les critères se complexifient. Bien que SQL Server 2008 améliore les performance des recherches mixtes (mi-fultext, mi relationel) ce type de requêtes nécessitent toujours des ressources importantes.

On les évite en :

==> Faisant des recherche relationnelles quand cela est possible, à base de LIKE par exemple, mais attention les index « classique » de SQL Server sont essentiellement efficace en recherchant par le début des chaînes de caractères (le LIKE '%xxx%' est très inefficace). De plus les index relationnel sont limités à 900 octets de données indexées par enregistrements.

Le parallélisme

Paralléliser la requête revient à l'exécuter sur plusieurs processeurs quand cela est possible. Le but est de réduire la durée de la requête souvent au détriment de la consommation processeur. Plus le nombre de processeur utilisé est important, plus le coût de la parallélisassions se fait ressentir.

On l'évite en :

==> Limitant le parallélisme au niveau de la requête ou au niveau du moteur de base de données.

http://blogs.codes-sources.com/christian/archive/2007/11/01/sql-server-r-gler-le-maxdop-ou-g-rer-le-parall-lisme-sur-sql-server.aspx

Les Tris et dérivés (JOIN, UNION, GROUP BY)

En dehors de la clause ORDER BY, il est tout un tas de scénario où le moteur de base de données utilise les tris, tel que pour la constitution des index, certaines jointures, etc. C'est le moteur de base de données, qui à la compilation va déterminer ce qui est le plus intéressant.

On les évite en :

==> En limitant les ORDER BY au nécessaire et en indexant convenablement les données. L'index clustered (ordonné) est le meilleur candidat à ce type d'optimisation. On le placera que les colonnes sur lesquelles se font les tris ou celles citées dans les GROUP BY. On essaiera aussi d'indexer les clefs étrangères des tables. Les vues indexées peuvent aussi se révéler une aide précieuse.

Les Requêtes traitant beaucoup de données

Même une requête renvoyant peu de données, peut se révéler être un gouffre en consommation de processeur. Un SUM sur une table comportant quelques millions d'enregistrements sera gourmande car non seulement une opération d'agrégat est à effectuer mais aussi car un grand nombre de données est à traiter. SQL Server devrait traiter toutes les pages via le processeur, même lorsque celles-ci sont déjà présentes en mémoire.

On les évite en :

==> En indexant correctement les données. Dans le cas du SUM un index seul sur cette colonne peut déjà significativement diminuer le temps de traitement. Une vue indexée sera là aussi très efficace.

Bonne optimisation . . .

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié jeudi 2 avril 2009 01:33 par christian

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01