Discussion :

[Débéa]

J'ai lu l'article que voici :

SQL Server : Votre serveur a-t-il un problème de CPU ?


Le CPU est l'une des ressources matérielle à laquelle il faut prêter attention sur un serveur de base de données (avec les ressources disques, mémoire et réseau).

Une requête qui est exécutée par le serveur est découpée en tâches, et chaque tâche peu se retrouver dans 2 files d'attente sur le serveur :

Wait Queue : Tâche en attente d'une ressource
Runnable Queue : Tâche en attente de s'exécuter sur l'un des processeurs
Le temps passé dans la Runnable Queue est un très bon indicateur de problème CPU. En effet il existe un Scheduler par CPU sur le serveur et chacun traite une tâche de manière coopérative. Tant que le CPU n'a pas finie la tâche en cours que celle-ci n'est pas bloquée par une attente de ressource, le CPU n'exécutera rien d'autre.

Sous SQL Server 2005 nous avons la vue sys.dm_os_wait_stats qui nous fournie ces informations, sous SQL Server 2000 (et 7 a priori) c'est la commande DBCC SQLPERF(WAITSTATS).

Il faut tout d'abord effacer les compteurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC SQLPERF(WAITSTATS, CLEAR)

Attendre un certains temps (quelques heures ou minutes suivant ce que vous souhaitez mesurer) puis…

Sous SQL Server 2005 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select   sum(signal_wait_time_ms) AS tps_attn_signal_ms,
         cast(100.0 * sum(signal_wait_time_ms) / sum(wait_time_ms) as numeric(20, 2)) AS pct_signal, 
         sum(wait_time_ms - signal_wait_time_ms) AS tps_attn_ressource_ms, 
         cast(100.0 * sum(wait_time_ms - signal_wait_time_ms) / sum(wait_time_ms) as numeric(20, 2)) AS pct_ressource 
from sys.dm_os_wait_stats

Sous SQL Server 2000 ou 7 :

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
create table #waitstats 
( 
   [wait_type]                nvarchar(120) not null, 
   [waiting_tasks_count]    bigint not null, 
   [wait_time_ms]            bigint not null, 
   [signal_wait_time_ms]    bigint not null 
) 
 
insert into #waitstats 
exec ('DBCC SQLPERF(WAITSTATS)') 
 
select   sum(signal_wait_time_ms) AS tps_attn_signal_ms,
         cast(100.0 * sum(signal_wait_time_ms) / sum(wait_time_ms) as numeric(20, 2)) AS pct_signal, 
         sum(wait_time_ms - signal_wait_time_ms) AS tps_attn_ressource_ms, 
         cast(100.0 * sum(wait_time_ms - signal_wait_time_ms) / sum(wait_time_ms) as numeric(20, 2)) AS pct_ressource 
from #waitstats

Le champ qui nous intéresse dans le résultat de la requête est pct_signal qui est la proportion d'attente du CPU, sa valeur doit généralement se situer en dessous de 20%. Au-delà de ce chiffre (si cela se produit constamment) il faudra soit penser à ajouter ou mettre à jour vos processeur, soit faire la chasse aux commandes consommatrices de CPU (tel que les tris et les compilations).

Bon tests…

De mon côté, j'ai systèmatiquement un pct_signal > à 20% (autour de 60% sur une semaine). Le serveur se porte bien est semble ne pas avoir de problème de CPU.

N'est-ce pas un peu exagéré ? Qu'en pensez-vous ?
Quelqu'un a t-il de l'expérience sur ce sujet ?
Faut-il que j'envisage vraiment d'augmenter la CPU ?

Merci d'avance pour vos réponses,

[SQLpro]

20% me parait franchement faible et dépend du nombre de processeur réels et virtuel. Sur un monoproc, j'aurais tendance à dire que 40% ne me gêne pas...

Enfin, la seule chose importante est de se demander si les temps de réponse globaux sont bon ou pas (au niveau utilisateur s'entend).

A +