SQL Server 2012 : RAM et Stat d'utilisation

Bonjour a tous,

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

Citation:

---

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.

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.

@++ ;)

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.

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?

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 ;)

@++ ;)

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:

---

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

---

++

Bonjours messieurs,

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

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

Code:

---

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

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:

---

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:

---

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.

@++ ;)

En complément :

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

Code:

---

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

---

++

Citation:

---

Envoyé par elsuket

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

---

Donc dans mon cas

Code:

---

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 ?

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.

++

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

Voir attachement.

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

@++ ;)

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

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

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.

@++ ;)

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

Citation:

---

En faisant cette petit appli

---

Laquelle ? :zoubi:

@++ ;)

Citation:

---

Envoyé par elsuket

Laquelle ? :zoubi:

@++ ;)

---

Bas celle dont j'ai posté les screenshots

OK ;)

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

@++ ;)

?!? lol

Je crois qu'on ne se comprend pas. Il s'agit d'une application qui n'as pas de nom.

J'ai créer un job sql qui tout les 15 minutes log le nombre de lectures et le nombre d'écritures dans chaque table ainsi que les Load_Factor etc...

Ensuite de quoi j'ai une appli développée par moi même en windev(beark) qui me sort des graphiques (dont j'ai posté les images)...

En logant aussi le temps qu'il me faut pour écrire les données dans cette table de statistiques, je peux me rendre compte de l'augmentation de charge de mon serveur au long de la journée...

Donc pas d'appli commerciale ni rien .
En revanche je veux bien poster les scripts si ça intéresse quelqu'un.

Salutations.