SQL Server 2016 : Diagnostic

Comprendre la notion d'attente

Testez gratuitement nos 1300 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Une tâche en cours d'exécution peut être arrêtée sur une condition extérieure. Examinez ce concept important du diagnostic.
05:40

Transcription

Avec l'ordonnanceur va la notion d'attente, qui est une notion très importante en diagnostic pour SQL Server. On résume la situation, comme je vous l'ai dessiné ici. Une tâche est exécutée sous forme de workers par un scheduler. À ce moment-là, le scheduler maintient trois composants, ou trois fils, ou trois zones, si vous voulez, qui sont importantes. La première zone s'appelle « Processor ». Donc, notre tâche est liée à un worker, le scheduler est en train de l'exécuter sur son processeur physique, et donc la tâche, le worker, devient un « worker thread », c'est-à-dire un worker qui a un numéro de thread et qui est vraiment en exécution, et, à ce moment-là, tout va bien, ma requête est en train d'être exécutée. Mais, par exemple, cette requête a besoin d'obtenir des données sur le disque. Il se trouve que le disque est saturé. Par exemple, il est en train de faire des lectures pour une autre requête. À ce moment-là, il faut bien attendre un petit peu que le disque se libère, mais le problème c'est que, si je suis en train d'attendre sur le processeur physique, je suis en train de bloquer des cycles de processeur pour rien finalement. Moi, je sais que j'attends. Donc, ce qui va se passer, c'est que le worker va informer le scheduler qu'il y a une attente, et le scheduler va dire « OK, je vais te mettre dans une file d'attente », qui s'appelle « Waiter », et puis je vais pouvoir libérer le processeur pour une autre tâche, pour un autre worker qui va pouvoir faire du travail en attendant. Ce que je viens de vous dire peut vous mettre aussi la puce à l'oreille sur l'intérêt d'avoir quelque chose comme SQL OS. Mon scheduler dans SQL OS est collaboratif, puisqu'il parle avec le worker, et qu'ils peuvent se mettre d'accord sur le fait de se déplacer dans la file Waiter pendant qu'il y a une attente. L'ordonnanceur de tâches de Windows, par exemple, est plus préemptif. Il ne peut pas communiquer avec les tâches, parce que Windows est un système d'exploitation généraliste, il ne sait pas quelle va être la nature des tâches qu'il va exécuter. Donc, il prend des décisions unilatérales en disant, « Voilà, toi, processus, ça fait 10 mns que tu tournes, eh bien, je vais te mettre de côté sans même savoir ce que tu es en train de faire. » Ici, c'est plutôt de l'ordonnancement coopératif, le scheduler et le worker en exécution peuvent se parler, le worker peut prendre la décision, ou dire au scheduler, « Voilà, je suis en train d'attendre donc, ça ne sert à rien que je reste ici à consommer des cycles de processeur. » Vous voyez, c'est vraiment beaucoup plus intéressant d'avoir un module comme SQL OS qui gère ce genre de choses. Parenthèses refermées. Maintenant, mon worker est en attente sur la libération du disque. Enfin, le disque devient disponible et on peut recommencer le travail, mais peut-être pas forcément tout de suite parce que j'ai peut-être un worker qui travaille déjà, qui est déjà attribué en Processor par mon ordonnanceur. À ce moment-là, le worker qui était en train d'attendre, qui est libéré, va se mettre dans une file qui s'appelle « Runnable », et dans Runnable, vous avez une liste de workers qui sont prêts à l'exécution, si le processeur n'est pas libre. Donc, au moment où le worker qui est en Processor a fini son travail, un worker qui est en Runnable peut prendre sa place immédiatement. Et si vous avez une tâche relativement longue, qui fait beaucoup d'attente, par exemple, on attend un peu sur le disque, le disque se libère, je peux recommencer à travailler. Et bien, ça peut arriver plusieurs fois pendant l'exécution d'un worker. Je vais peut-être attendre 10 fois ou 20 fois sur la libération, à chaque fois, du disque, et à ce moment-là, je vais passer ma vie à faire comme ceci. Je suis en Processor, mais je dois attendre, je viens dans Waiter, j'attends quelques millisecondes, et enfin le disque est libre, je me mets dans Runnable. Je vais dans Processor, je travaille un petit peu, et je dois de nouveau attendre, et je fais une boucle comme ceci. Vous voyez que ça peut être intéressant de le savoir, parce que si vous analysez une requête, et que vous regardez sur quoi elle va attendre, ça peut vous donner des indications sur la charge du système et sur ce que vous pouvez améliorer dans votre système ou dans une requête pour faire en sorte que votre serveur soit plus performant. Une dernière note à ce sujet. La tâche qui est en Processor n'est pas interrompue par l'ordonnanceur. Il y a collaboration, ça c'est dit, mais elle n'est pas interrompue non plus de façon unilatérale par le scheduler. Ce qui se passe, c'est que si moi en tant que worker, je travaille et je n'ai pas d'attente, je vais pouvoir finir mon travail. Enfin, presque, parce que j'ai aussi ce qu'on appelle un « quantum ». Il y a une durée, qui est de quelques millisecondes, pas grand-chose, mais il y a une durée maximum d'exécution sur un scheduler dans cet état Processor. Si j'atteins mon quantum, c'est-à-dire que si je travaille sans interruption, sans attente, pendant quelques millisecondes, et soudain j'atteins mon quantum, je vais moi-même dire, « OK, j'atteins ma limite, mets-moi directement en Runnable ici, » comme ça le scheduler peut planifier du travail pour d'autres workers qui sont en attente. Donc, ça partage un petit peu le travail. Donc, ce worker se retrouve en Runnable. S'il n'y a rien d'autre qui attend sur le processeur, il fait comme ça, il passe en Runnable, il retombe directement en Processor. Par contre, si d'autres workers étaient en attente, il passe en Runnable, il laisse la place, et puis il va reprendre sa place quand l'autre worker aura atteint son quantum ou sera en attente de quelque chose. ce qui permet de bien équilibrer la charge sur chaque processeur, avec ces ordonnanceurs, et pour le nombre de workers qu'ils doivent gérer.

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 !