Discussion :

[carpi751]

Bonjour,

J'observe une chose étrange sur un serveur SQL2005SP2: l'interrogation de la vue dm_exec_query_stats me retourne aucune ligne ! Comment est-ce possible (dataserver utilisé en permanence) ?

2eme chose qui est certainement en rapport, le process interne "RESOURCE MONITOR" consomme en permanence une grande partie d'un des CPU (confirmé à l'aide du perfmon).

Enfin, le procedure cache ratio est de 42%, ce qui est vraiment faible (97% pour le buffer cache). Comment expliquer cette chute alors qu'il n'y a eu aucun changement effectué !

Avez-vous une piste pour m'aider ?

Merci;

Bonne journée !

[elsuket]

Bonjour,

J'observe une chose étrange sur un serveur SQL2005SP2: l'interrogation de la vue dm_exec_query_stats me retourne aucune ligne ! Comment est-ce possible (dataserver utilisé en permanence) ?

Disposez-vous de l'autorisation VIEW SERVER STATE sur le serveur ?

Comment expliquer cette chute alors qu'il n'y a eu aucun changement effectué !

Changement par rapport à quoi ?

@++

[carpi751]

Oui j'ai l'autorisation. Aucun changement du type : DBCC FREEPROCACHE ou DROPCLEANBUFFERS lancés, etc...

Pendant plusieurs heures, j'ai 0 ligne retournée par la DMV (pendant ce laps de temps, le process RESSOURCE MONITOR consomme bcp de CPU). Brutalement (aujourd'hui par exemple au bout de 8h), la dmv me retourne des records (et le ressource monitor ne consomme plus de cpu).
Je n'y comprends rien !

[elsuket]

Difficile de diagnostiquer sans avoir la machine sous la main, mais je pense à une pression mémoire.
Si le moniteur de ressource consomme beaucoup de CPU, c'est que la purge des buffers par le LazyWriter coûte cher, c'est-à-dire que SQL Server doit les vider trop souvent (par manque de mémoire), ce qui expliquerait la consommation de CPU.

Cela expliquerait également l'absence de lignes lorsque vous requêtez la DMV sys.dm_exec_query_stats, puisque SQL Server ne collecte des données de performance que si la "capacité" système le permet.

Démarrez Perfmon et regardez la valeur du compteur Lazy Writes/sec ou Ecritures de pages/s de l'objet de performance SQL Server : Buffer Manager.
Vérifiez également la valeur du compteur Page Life Expectancy ou Espérance de vie d'une page, toujours dans le même objet de performance.
Si ce compteur est en-dessous de 300, cela indique que les pages de données du Buffer Manager sont purgées trop souvent.
Dans ce cas ce sera comme je vous l'ai précisé un peu plus haut : cela oblige SQL Server à écrire les pages du gestionnaire de tampons, et donc à augmenter sa consommation en CPU.

Attention tout de même à le corréler avec le compteur Checkpoints Pages/sec ou en français Pages de points de contrôle/s : normalement c'est le CHECKPOINT qui vide les pages du buffer.
Celui-ci se produit par défaut toutes les minutes, sauf si vous avez changé la valeur de l'option recovery interval (min) à l'aide de la procédure stockée sp_configure.
Pour savoir quelle valeur est utilisée pour cette option, exécutez :

Code :

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

1
2
3
SELECT *
FROM sys.configurations
WHERE name = 'recovery interval (min)'

Si la colonne value_in_use vaut 0, c'est que le CHECKPOINT est configuré par défaut.
Également lors de l'occurrence d'un CHECKPOINT, le compteur d'espérance de vie d'une page va chuter.
Si ce compteur remonte après le CHECKPOINT c'est normal, en revanche si par la suite vous remarquez que celui-ci est autour ou en-dessous de 300, pensez à acheter de la RAM

@++

[carpi751]

Merci pour cette derniere reponse, j'avais effectivement controlé differents compteurs sous Perfmon (procedure cache hit ratio, page life exp, etc...)), j'observais des valeurs etonnantes (environ 40% pour le procedure cache par exemple).

Apres recherche, j'ai trouvé une KB se rapportant completement à mon pb observé sur differents dataservers : KB 948450

"FIX: CPU utilization of a CPU in a single node increases to 100 percent when you use SQL Server 2005 on a multiprocessor computer that uses NUMA architecture "

http://support.microsoft.com/kb/948450/en-us

Pb résolu en installant le Cumulative Fix 7 pour SQL2005SP2 ou installation
du SP3.

Merci.

[elsuket]

Merci bien pour ce retour

Est-ce à dire que tu peux marquer le sujet comme résolu ?

@++