SQL Server 2016 : Diagnostic

Comprendre les compteurs

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Pour superviser un serveur SQL Server, vous devez connaître et suivre les compteurs les plus importants.
08:40

Transcription

Me voici avec mon moniteur de performance et les compteurs que j'ai ajoutés qui correspondent aux compteurs que j'ai indiqués dans mon document, (vous pouvez aller chercher sur docs.com ou sur mon site www.babaluga.com également. Vous le trouverez également là). Je vous explique dans ce document pourquoi mais, bien sûr, on va le voir dans cette vidéo. Première chose, j'ai un affichage ici en graphe, c'est intéressant pour voir historiquement l'évolution de ces compteurs. C'est chaque fois des mesures chiffrées, bien sûr. J'ai beaucoup de compteurs et là, j'ai plein de choses qui se mélangent avec des couleurs, c'est pas très, très visible. Finalement, les graphes, c'est intéressant pour voir les processeurs, pour voir l'évolution à travers le temps ou de la charge des processeurs. Mais, avec beaucoup de compteurs comme ceci, c'est pas très, très lisible. Donc, je vais basculer, en cliquant ici, sur un affichage plutôt de mode rapport, qui va afficher, en temps réel, sans graphe historique, les valeurs du moment. Je vais avoir ici, montant processeur, je vois que je suis à peu près à 50, 30, 43, donc, je suis sur une moyenne de 30 à 50% d'utilisation du processeur. C'est pas mal! J'ai pris le disque physique, donc je veux savoir quelles sont les moyennes de temps d'une écriture ou d'une lecture en secondes. Par exemple, si mes écritures ont une latence moyenne de 25 millisecondes, et bien, j'aurai 0,025 ici, et puis, cela me permettra de juger les conditions de latence moyenne de mes disques. Ça, on en a parlé déjà. Ici, les recommandations, par exemple en lecture, c'est d'être en dessous de 0,025 donc, de 25 millisecondes de latence, car 25 millisecondes de latence, c'est déjà pas mal pour un disque, on peut quand même espérer, sur des disques, on a de la latence comme 10 ou 15 millisecondes, 25, ça commence à être un petit peu pénible, surtout, si c'est en permanence. Donc, on peut juger avec ça des performances du disque. Le processeur, c'est clair, on l'a dit, buffer cache hit ratio, Quel est le pourcentage de pages qui sont prises dans le buffer, par rapport aux quelques milliers de pages utilisées par le moteur de stockage? Vous faites des requêtes, ces requêtes ont besoin de pages de données, ce compteur calcule sur les quelques derniers milliers de pages de données, combien de ces pages ont été prises dans le cache de données directement. Si vous avez, comme ici, un ratio de 100% c'est qu'il n'y a eu aucune lecture sur le disque et c'est très bien, et donc, le disque, voyez, est tout calme. Par contre, si vous descendez à 96, 95, 94 ça veut dire que sur 1000 pages, et bien, vous en avez eu quelques dizaines qui ont été prises sur le disque. Et plus le pourcentage diminue, plus ici, normalement, votre activité, surtout en lecture, va augmenter ; vous pourrez donc corréler les deux. Mais si vous avez un buffer cache hit ratio qui est bas, par exemple, 94, 93, sur une base de données de taille raisonnable, de taille moyenne, si vous avez des bases de données très volumineuses, où on fait des lectures sur très gros volumes de données, c'est relativement plus normal. Par contre, sur une base de données de taille moyenne, vous pourriez vous dire, peut-être qu'il manque de la RAM, ou peut-être, qu'il y a des requêtes qui n'ont pas assez d'index et qui scannent des tables, il faudrait peut être optimiser les requêtes, comme on en a parlé sur notre réflexion, ne pas sauter sur les conclusions directement. Ensuite, le page life expectancy, c'est un compteur qu'on peut corréler, ce sont deux compteurs importants du buffer, pour juger de la RAM finalement. ici, le ratio, c'est important, mais le page life expectancy l'est également. C'est l'espérance de vie d'une page dans le buffer au nombre de secondes. Dans le buffer, on monte des pages et on les conserve tant qu'il reste de la place. Donc, si vous avez une forte espérance de vie d'une page, comme c'est le cas ici, ça veut dire que la page peut rester longtemps, qu'elle ne va pas être vidée et donc, on aura suffisamment de RAM pour avoir de bonnes performances du buffer. Si par contre, cette valeur est très basse ça veut dire que très régulièrement, la page qui est montée doit être vidée et donc il faut qu'elle remonte tout le temps et donc, on va avoir un buffer cache hit ratio qui diminue, et puis on va avoir des moyennes de lectures du disque qui sont importantes également. Quelle est la bonne valeur ici, ça, c'est une bonne question ! Historiquement, on avait un calcul qui était fait par Microsoft et qui disait : il faut que ce soit au-dessus de 300. Mais 300 secondes, c'était à l'époque où on avait des serveurs avec 4 Giga de RAM, donc, on fait un petit calcul, une petite règle de trois, où on dit, combien de fois j'ai 4 Giga de RAM, par exemple, si j'ai 12 Giga de RAM sur ma machine, j'ai trois fois 4 Giga de RAM, et on multiplie la vieille valeur recommandée par Microsoft, qui est 300 par trois, donc, on va dire 900 sur un serveur de 12 Giga de RAM, c'est à peu près le minimum syndical pour avoir un page life expectancy correct. Vous voyez ici qu'il est nettement supérieur, donc je suis tranquille, mais plus ce page life expectancy est élevé, plus, vous êtes tranquille au niveau de la RAM et au niveau du buffer. Donc, avec ces compteurs, vous avez, je vous les entoure, ici, les performances du disque, c'est très, très bien ; ici, le processeur, ici, la RAM finalement, donc, rien qu'avec ça, vous avez une bonne vue générale, qui va vous permettre d'identifier assez rapidement si un problème se pose. Pourquoi est-ce que j'ai ajouté le reste, et bien, finalement, parce que ceci également peut être un bon indicateur de la RAM, si mon nombre d'objets en mémoire dans le cache de plan est stable, ou augmente petit à petit, cela veut dire qu'il y a assez de RAM. Si par contre, tout à coup il chute, c'est pas grave, deux ou trois fois par jour. Par exemple, on a fait une opération particulière sur la base et ça re-vide le cache mais, si, régulièrement dans la journée, il monte, il chute, il remonte, il rechute, il remonte, il rechute en permanence, ça veut dire que, quelque chose doit vider ce cache de plan, peut-être une pression sur la mémoire ; ça peut être un signe qu'on a des problèmes pas assez de RAM, par exemple, ou un problème de configuration, ça, c'est possible également. Et ensuite, mes deux derniers compteurs, les transactions par seconde dans les deux bases de données, quelle est l'activité finalement dans ces bases, et quelle est l'activité dans ces bases par rapport à l'activité totale, et puis, le patch request par seconde, moi, je l'aime beaucoup parce que c'est un indicateur simple, clair, du nombre de requêtes finalement de la charge, quelque part, de mon serveur et que je peux corréler avec les autres. Par exemple si la charge est, en moyenne, de 3.000 batchs par seconde, et que, je suis, à un temps processeur de 25% et si, tout à coup, je monte à 3.200 et que mon temps processeur passe à 50, de 25 à 50, on passe de 3.000 à 3.200 batchs par seconde mais on passe de 25% à 50% du processeur. Pour moi, ça veut dire qu'il faut que je m'attende à des problèmes. On augmente un petit peu la charge et ça augmente de beaucoup les processeurs donc la machine n'a peut-être plus assez de marge pour supporter une augmentation de la charge. Ça peut être tout à fait le signe qu'il y a des requêtes sur lesquelles il faut travailler pour optimiser ces requêtes parce-qu'elles sont peut être très lourdes et qu'elles vont sérieusement frapper le serveur, elles vont sérieusement le charger, c'est peut-être aussi un signe que la machine est à la limite de ses capacités, 3.000 batchs request par seconde, ça doit aller quand même, ça dépend lesquelles bien sûr mais vous voyez, vous pouvez corréler cette activité de SQL serveur avec finalement ces compteurs, les compteurs du disque également et éventuellement, les compteurs de la RAM. Ça vous permet de dire, par rapport à une activité moyenne, voici le comportement moyen. Et donc vous connaissez votre serveur, vous récupérez, par exemple, ces compteurs en les graphant dans des outils. Il y a des outils commerciaux, comme What'sUp, il y a des outils libres, comme Nagios ou Cacti, qui vous permettent de récupérer ces informations et de maintenir un historique, des graphes, de façon à pouvoir juger à travers le temps, l'évolution de votre serveur, quel est son comportement à travers la journée, la semaine, le mois de façon à pouvoir bien le connaître et d'être capable d'identifier un changement, une dégradation, une augmentation de nombre de batchs request par seconde bref, vraiment du diagnostic pro-actif, et prophylactique également.

SQL Server 2016 : Diagnostic

Prenez en main les outils de diagnostic intégrés à SQL Server. Soyez en mesure de comprendre et d'analyser les problèmes de performance rencontrés le plus fréquemment.

1h58 (20 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :14 déc. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !