![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Un petit post sur la planification de t\u00e2ches sur Adaptive Server.<\/p>\n
Globalement, ASE utilise des threads pour supporter toutes les t\u00e2ches qu’il ex\u00e9cute: requ\u00eates, IO r\u00e9seau ou disque, connexions utilisateur, t\u00e2ches internes… en conjonction avec son propre planificateur de t\u00e2che.<\/p>\n
Le r\u00f4le du planificateur de t\u00e2che sur tout syst\u00e8me est de partager le temps d’un CPU entre plusieurs unit\u00e9s d’ex\u00e9cution (t\u00e2ches). Il existe deux grandes familles de planificateurs, les pr\u00e9emptifs<\/strong>, et les coop\u00e9ratifs<\/strong>.<\/p>\n Le planificateur pr\u00e9emptif <\/strong>a le pouvoir de planifier et d’interrompre les t\u00e2ches selon des r\u00e8gles qui lui sont propres et sans tenir compte du type de t\u00e2che en cours d’ex\u00e9cution. One size fits all<\/em>, comme on dit. Ce m\u00e9canisme, qui garantit qu’aucune t\u00e2che ne va monopoliser les ressources CPU, permet \u00e0 chaque programme de pouvoir avoir la main sur la CPU \u00e0 un moment o\u00f9 un autre. Sur la plupart des OS (linux, UNIX System V et Windows NT \u00e0 partir de la 4.0), le planificateur alloue au thread un bail d’ex\u00e9cution ou un quanti\u00e8me. Si la t\u00e2che n’a pas termin\u00e9 son travail dans le temps imparti, elle est interrompue. Lorsqu’il interrompt la t\u00e2che en cours, le planificateur sauvegarde son contexte dans un coin (c’est \u00e0 dire les structures process + thread qui la repr\u00e9sentent en m\u00e9moire), et planifie une nouvelle t\u00e2che sur la CPU. Ce qu’on appelle un changement de contexte<\/em>.<\/p>\n Le planificateur coop\u00e9ratif<\/strong>, lui, va au contraire laisser \u00e0 la t\u00e2che le soin de se terminer toute seule. C’est l\u00e0 la plus grosse diff\u00e9rence, il n’interrompt pas une t\u00e2che qui n’a pas termin\u00e9 son travail. C’est \u00e0 la charge de la t\u00e2che de rendre la main pour laisser de la place aux autres, c’est donc \u00e0 elle de pr\u00e9voir un m\u00e9canisme de rel\u00e2che (to yield<\/em> = “c\u00e9der”). Windows 3.1 employait un scheduler coop\u00e9ratif, les Windows 98 et 95 aussi pour assurer la compatibilit\u00e9 avec les programmes 16 bits.<\/p>\n Maintenant, on imagine facilement le risque d’employer un tel syst\u00e8me de planification: une t\u00e2che qui part en vrille ne lib\u00e8rera jamais la CPU, \u00e7a n’a donc plus \u00e9t\u00e9 employ\u00e9 pour faire des operating systems.<\/p>\n Micheal Stonebraker<\/a> avait publi\u00e9 un article de quelques pages au d\u00e9but des ann\u00e9es 80* expliquant en gros que les ‘services’ apport\u00e9s par UNIX system V n’\u00e9taient pas adapt\u00e9s au monde de la base de donn\u00e9es, et notamment en mati\u00e8re de planification. Les t\u00e2ches typiques issues des SGBD prennent plus de temps \u00e0 s’effectuer car il ne s’agit pas de calcul mais d’IOs, et le mode pr\u00e9emptif n’est pas adapt\u00e9 car il ‘coupe’ la dynamique et l’efficacit\u00e9 du SGBD en produisant de nombreux changements de contexte.<\/p>\n Donc les d\u00e9veloppeurs chez Sybase ont r\u00e9pondu en cr\u00e9ant un scheduler coop\u00e9ratif ‘on top<\/em>‘ **, propre \u00e0 Adaptive Server et par dessus le planificateur de l’OS, de telle mani\u00e8re \u00e0 ce qu’il masque les choses vis \u00e0 vis de celui-ci et limite au maximum les changements de contexte.<\/p>\n – Les tranches de temps:<\/strong> Tout ceci se passe toujours sans que l’OS ne sache rien, car de son c\u00f4t\u00e9, le processus dataserver est toujours en ex\u00e9cution. C’est le but: l’OS ne doit pas interrompre le processus dataserver puisque celui-ci semble toujours travailler.<\/p>\n – Runnable Process search count:<\/strong> Pour illustrer tout \u00e7a, une petite explication de la section ‘kernel’ de sp_sysmon:<\/p>\n Avant de commencer, il faut bien rappeler le cheminement de la boucle: Chaque engine tient le compte de ticks re\u00e7us de l’OS (par le biais de signaux SIGALRM) tous les 100ms, et les r\u00e9pertorie selon trois cat\u00e9gories:<\/p>\n CPU Busy<\/strong>: repr\u00e9sente le temps (en fait le nombre de ticks ramen\u00e9 en pourcentage) pass\u00e9 par l’engine \u00e0 ex\u00e9cuter une t\u00e2che sur l’intervalle. On peut retrouver ces valeurs brutes en interrogeant les variables globales @@cpu_busy, @@idle, et @@io_busy. La dur\u00e9e d’un tick peut \u00eatre retrouv\u00e9e avec @@timeticks.<\/p>\n A+. [ David B. ]<\/p>\n *: Michael Stonebraker, Operating System Support for Database Management, CACM 24(7), p412-418 (1981).
\nASE va donc fonctionner comme un OS, mais avec ses r\u00e8gles \u00e0 lui: il g\u00e8re sa propre planification, son propre partage du temps CPU, ses propres valeurs de quanti\u00e8me. Car bien que coop\u00e9ratif, il doit pouvoir stopper une t\u00e2che qui ne r\u00e9pond plus et \u00e9viter la saturation d’un engine. Lorsqu’il planifie une t\u00e2che, il va lui allouer un bail. Ce bail n’est pas une valeur temporelle, c’est un nombre de ticks d’horloge qui est d\u00e9cr\u00e9ment\u00e9. Il est calcul\u00e9 en divisant le param\u00e8tre ‘timeslice’ par ‘sql server clock tick length’. Comme les deux valeurs sont \u00e0 100 ms par d\u00e9faut, le nombre de ticks d’horloge autoris\u00e9 est de 1. Dans le d\u00e9roulement de son ex\u00e9cution, une t\u00e2che va passer par des parties de code qu’on appelle des yield points<\/em>, au cours desquels elle va prendre une seconde pour v\u00e9rifier qu’elle n’a pas d\u00e9pass\u00e9 son bail. Si elle d\u00e9couvre que le bail est exc\u00e9d\u00e9 (bail < 0), elle va demander \u00e0 ASE de lui accorder une grace suppl\u00e9mentaire (cpu grace time<\/em>), qui peut aller jusqu’\u00e0 500 ticks (soit 50 secondes). Si elle n’a pas termin\u00e9 au del\u00e0 de cette valeur, alors ASE sort les gros moyens, termine la t\u00e2che, annule ses transactions et affiche une stacktrace dans l’errorlog:<\/p>\n00:00000:00005:2007\/04\/02 22:09:24.07 kernel timeslice -501, current process infected\r\n00:00000:00005:2007\/04\/02 22:09:24.75 kernel ************************************\r\n00:00000:00005:2007\/04\/02 22:09:24.77 kernel curdb = 1 tempdb = 2 pstat = 0x200\r\n00:00000:00005:2007\/04\/02 22:09:24.77 kernel lasterror = 0 preverror = 0 transtate = 1\r\n00:00000:00005:2007\/04\/02 22:09:24.77 kernel curcmd = 0 program =\r\n...<\/pre>\n
\nToujours dans le souci de pr\u00e9server son ex\u00e9cution vis \u00e0 vis de l’OS, lorsqu’il a termin\u00e9 d’ex\u00e9cuter des t\u00e2ches, et plut\u00f4t que de rendre la main tout de suite, Adaptive Server va entrer dans une boucle de v\u00e9rification des IOs en attente c\u00f4t\u00e9 r\u00e9seau puis c\u00f4t\u00e9 disque. S’il ne trouve rien, il va tourner (spinning<\/em>) pour rechercher de nouvelles t\u00e2ches en attente d’ex\u00e9cution, puis de nouvelles IOs r\u00e9seau, puis de nouvelles IOs disques, etc… tout \u00e7a 2000 fois par d\u00e9faut (runnable process search count<\/em>), m\u00eame s’il n’y a rien \u00e0 traiter dans aucune file d’attente. Ce qui donne une apparente sensation d’hyperactivit\u00e9 c\u00f4t\u00e9 OS, alors que c\u00f4t\u00e9 Adaptive Sever, l’\u00e9lectro-enc\u00e9phalo est plut\u00f4t plat.<\/p>\nKernel Utilization\r\n------------------\r\n\r\nYour Runnable Process Search Count is set to 5000\r\nand I\/O Polling Process Count is set to 10\r\n\r\nEngine Busy Utilization CPU Busy I\/O Busy Idle\r\n------------------------ -------- -------- --------\r\nEngine 0 80.0 % 7.5 % 12.5 %\r\nEngine 1 80.8 % 6.0 % 13.2 %\r\nEngine 2 82.5 % 5.7 % 11.9 %\r\nEngine 3 84.0 % 6.7 % 9.3 %\r\nEngine 4 79.0 % 6.8 % 14.2 %\r\nEngine 5 80.0 % 7.3 % 12.7 %\r\nEngine 6 79.6 % 8.3 % 12.0 %\r\n------------------------ -------- -------- --------\r\nSummary Total 565.9 % 48.4 % 85.7 %\r\nAverage 80.8 % 6.9 % 12.2 %<\/pre>\n
\n![\"\"](\"https:\/\/www.alldb.fr\/blog\/wp-content\/uploads\/2009\/06\/rpsc3-300x140.png\")
<\/a>
\n<\/a><\/p>\n
\nIdle<\/strong>: repr\u00e9sente le temps pass\u00e9 par l’engine \u00e0 n’ex\u00e9cuter aucune t\u00e2che sur l’intervalle.
\n I\/O Busy<\/strong>: est une soustraction de Idle. Il s’agit du temps pass\u00e9 par l’engine \u00e0 n’ex\u00e9cuter aucune t\u00e2che (donc Idle) mais o\u00f9 il y avait au moins une IO disque en attente dans la file. Elle repr\u00e9sente donc la quantit\u00e9 de temps o\u00f9 l’engine n’a pas pu ex\u00e9cuter une t\u00e2che parce qu’il y avait au moins une IO disque en attente.<\/p>\n
\n**: et Microsoft fit de m\u00eame <\/em>en dotant <\/em>SQL Server 7.0 de son propre scheduler coop\u00e9ratif (UMS), toujours bien pr\u00e9sent en version 2008 sous une autre d\u00e9nomination (SQLOS). <\/em><\/p>\n
![\n<\/a><\/p>\nChaque engine tient le compte de ticks re\u00e7us de l’OS (par le biais de signaux SIGALRM) tous les 100ms, et les r\u00e9pertorie selon trois cat\u00e9gories:<\/p>\nCPU Busy<\/strong>: repr\u00e9sente le temps (en fait le nombre de ticks ramen\u00e9 en pourcentage) pass\u00e9 par l’engine \u00e0 ex\u00e9cuter une t\u00e2che sur l’intervalle.\nIdle<\/strong>: repr\u00e9sente le temps pass\u00e9 par l’engine \u00e0 n’ex\u00e9cuter aucune t\u00e2che sur l’intervalle.\n I\/O Busy<\/strong>: est une soustraction de Idle. Il s’agit du temps pass\u00e9 par l’engine \u00e0 n’ex\u00e9cuter aucune t\u00e2che (donc Idle) mais o\u00f9 il y avait au moins une IO disque en attente dans la file. Elle repr\u00e9sente donc la quantit\u00e9 de temps o\u00f9 l’engine n’a pas pu ex\u00e9cuter une t\u00e2che parce qu’il y avait au moins une IO disque en attente.<\/p>\nOn peut retrouver ces valeurs brutes en interrogeant les variables globales @@cpu_busy, @@idle, et @@io_busy. La dur\u00e9e d’un tick peut \u00eatre retrouv\u00e9e avec @@timeticks.<\/p>\nA+. [ David B. ]<\/p>\n*: Michael Stonebraker, Operating System Support for Database Management, CACM 24(7), p412-418 (1981).\n**: et Microsoft fit de m\u00eame <\/em>en dotant <\/em>SQL Server 7.0 de son propre scheduler coop\u00e9ratif (UMS), toujours bien pr\u00e9sent en version 2008 sous une autre d\u00e9nomination (SQLOS). <\/em><\/p>\n](\"https:\/\/www.alldb.fr\/blogs\/wp-content\/uploads\/2009\/06\/rpsc2.png\"){kind=link}