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 . . .
