Discussion :

[Donpi]

Bonjour a tous,

Dans un article de SQLPro il fait mention de la quantité de RAM à alloué a l'instance SQL.

en premier la RAM qui doit être calculé par rapport à la fenêtre des données (le volume des 20% de données qui sont utilisées à 80% - Loi de Pareto...)

Du coup comment savoir quel sont les tables les plus utilisées?

Je sais comment sortir des statistiques sur les indexes, les requêtes et autre.
Mais pas sur les tables.

[elsuket]

Bonjour,

Cela peut se faire de plusieurs façons :

- soit en étudiant les statistiques d'utilisation des index, avec la requête que je viens de publier ici
- soit en étudiant l'occupation du cache de données à l'aide des requêtes que je viens de publier ici
- soit en créant une session d'événements étendus (à partir de SQL Server 2008) qui enregistre dans un anneau de mémoire les acquisitions de verrous sur les tables d'une base de données en particulier. Cela peut néanmoins pénaliser un peu les performances durant l'audit.

Normalement un recoupement des deux premiers éléments de la liste donne quelque chose de relativement précis, auquel il faut ajouter une marge de sécurité en vue de l'augmentation inévitable du volume de la base de données.

@++

[darkelend]

Bonjour,
Si tu utilises mon application (c'est gratuit : http://www.kankuru.fr), tu auras accès aux statistiques d'utilisation de la RAM d'une instance par base de données et par table.

[Donpi]

Est ce qu si je prend la volume du top 16% (20% de 80%) de mes tables triée selon le nombre d'écriture et de lecture de leur indexes, j'ai une approximation valable de la RAM nécessaire?

[elsuket]

Non, parce qu'on ne sait pas si votre instance SQL Server est sous pression mémoire ou disque

Prenez la première requête que donne Glen Berry et dites-nous ce que obtenez

@++

[mikedavem]

On peut également recouper les informations proposés par Elsuket avec les compteurs de performances associés à l'utilisation de la mémoire via le buffer pool de SQL Server.

La seule vraie méthode pour déterminer si la quantité de RAM est suffisante pour un serveur de bases de données pour une charge donnée est le test + monitoring.

Code :

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

1
2
3
4
MSSQLServer:Buffer Manager:Buffer Cache Hit Ratio
MSSQLServer:Buffer Manager:Page Life Expectancy
MSSQLServer:Buffer Manager:Target Pages
MSSQLServer:Buffer Manager:Lazy Writes / sec

++

[Donpi]

Bonjours messieurs,

Effectivement la "formule" que j'ai proposé m'indique 63Go de ram

sinon voilà le résultat du script de "Glen Berry"

Code :

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

1
2
3
4
5
6
7
 
wait_type				wait_time_s	pct	running_pct
CXPACKET				935465.12	54.19	54.19
SQLTRACE_INCREMENTAL_FLUSH_SLEEP	424166.35	24.57	78.76
ASYNC_NETWORK_IO			228152.29	13.22	91.98
PAGEIOLATCH_SH				49744.83	2.88	94.86
BACKUPIO				23068.61	1.34	96.20

C'est des données prod

[elsuket]

Apparemment ça parallélise un peu (CXPACKET), donc il est possible que le serveur subisse un peu de pression CPU ...

Mais ce n'est à priori pas méchant puisque le type d'attente suivant est une attente SQL Trace, et il est dû à la trace par défaut, sauf si vous avez une autre trace qui tourne ... Pour le confirmer, exécutez :

Code :

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

1
2
3
SELECT	*
FROM	sys.traces
WHERE	id > 1

S'il n'y a aucune ligne retournée, c'est que seule la trace par défaut (qui porte toujours l'id 1) est exécutée.

Pour confirmer s'il y a ou non pression CPU :

- vous pouvez utiliser des compteurs de performance
- vous pouvez enregistrer le résultat de la requête suivante :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT	scheduler_id
	, is_online
	, is_idle
	, current_tasks_count
	, runnable_tasks_count
	, work_queue_count
	, load_factor
FROM	sys.dm_os_schedulers
WHERE	scheduler_id < 255

On filtre sur le scheduler_id car ceux qui sont supérieurs à 255 sont ceux pour les backups, les connexions d'administrateur dédiée, ...

il n'y a pas de véritable valeur "seuil" au dessus de laquelle on peut dire avec certitude qu'il y a un problème. Les colonnes runnable_tasks_count, work_queue_count et load_factor doivent montrer des nombres les plus petits possible. En général un load factor supérieur à 10 de façon constante est un problème.

Les causes sont souvent :

- absence de maintenance des statistiques (le plus courant et le plus simple à résoudre)

- index manquants (courant)

- prédicats non-cherchables (courant)

- requêtes non paramétrées : typiquement en SQL dynamique (EXEC(@sql)) avec absence d'utilisation de sp_executesql et de paramètres, ce qui produit un plan par exécution de la procédure à chaque changement de valeur, donc une compilation, donc une surconsommation CPU (assez courant)

- conversions implicites (courant mais pas facile à détecter : il faut scruter le cache de plans) dues à une utilisation incorrecte des types de données dans un prédicat de jointure ou de filtrage (typiquement une variable de type int qui filtre sur une colonne en varchar)

- plus rare : reniflage de paramètres (parameter sniffing dans la littérature) : L'optimiseur de requêtes produit un plan en fonction des valeurs des paramètres de la première exécution, qui ne conviennent à certaines valeurs de paramètres. En déclarant localement des variables et en les affectant à la valeur des paramètres coupables, la requête s'exécute au moins de façon acceptable, si ce n'est performante.

@++

[mikedavem]

En complément :

Pour trouver les requêtes concernés par des plans d'exécutions parallèles :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT query_plan AS CompleteQueryPlan ,
 n.value('(@StatementText)[1]', 'VARCHAR(4000)') AS StatementText ,
 n.value('(@StatementOptmLevel)[1]', 'VARCHAR(25)') AS StatementOptimizationLevel ,
 n.value('(@StatementSubTreeCost)[1]', 'VARCHAR(128)')
AS StatementSubTreeCost ,
 n.query('.') AS ParallelSubTreeXML ,
 ecp.usecounts ,
 ecp.size_in_bytes
FROM sys.dm_exec_cached_plans AS ecp
CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS eqp
CROSS APPLY query_plan.nodes
('/ShowPlanXML/BatchSequence/Batch/Statements/StmtSimple')
AS qn ( n )
WHERE n.query('.').exist('//RelOp[@PhysicalOp="Parallelism"]') = 1

++

[Donpi]

En général un load factor supérieur à 10 de façon constante est un problème.

Donc dans mon cas

Code :

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

1
2
3
scheduler_id	is_online	is_idle		current_tasks_count	runnable_tasks_count	work_queue_count	load_factor
0		1		1		11			0			0			14
1		1		0		17			0			0			17

je dois flipper ?

[mikedavem]

Les valeurs données par Elsuket sont des seuils théoriques.
Dans ton cas, je dirais que cela ne revèle pas forcément un problème car visiblement il n'y a pas de tâches en attente. Cela peut vouloir dire que la charge de travail est là (load factor important) mais que les processeurs répondent bien pour le moment (pas de tâches qui s'empilent dans les files d'attentes des processeurs).

Bien sûr il faudrait avoir un relevé de ces métriques dans le temps pour pouvoir répondre correctement.

++

[Donpi]

Re, alors je n'ai pas relevé toutes les info, uniquement current_tasks_count est load_factor.

Voir attachement.

[elsuket]

Erf ... il aurait mieux valu tracer runnable_tasks_count et work_queue_count

@++

[Donpi]

Ouais forcement ... bon bas je vais voir si j'arrive a avoir quelque chose d'ici la fin de l'après midi

[Donpi]

voila ce que ça donne. ( j'ai effectivement un gros traitement ce matin )

[elsuket]

Je ne trouve pas cela catastrophique, cela dit nous n'avons pas les valeurs de work_queue_count

il vous faut auditer les deux en même temps, avec l'utilisation CPU en %.
Ne réalisez pas l'audit par scheduler : prenez plutôt _Total.

@++

[Donpi]

Merci.

En faisant cette petit appli pour suivre l'utilisation de ma base je suis tomber sur plusieurs sources de ralentissements...

Je vais déjà résoudre ces points là.

On peut considérer ce sujet comme clos mais je me permettrais malgré tout de revenir par la suite avec des points un peu plus précis dans un nouveau Topique.


Merci encore.

[elsuket]

En faisant cette petit appli

Laquelle ?

@++

[Donpi]

Laquelle ?

@++

Bas celle dont j'ai posté les screenshots

[elsuket]

OK

Au passage, on peut avoir le nom de l'application ?

@++