![\"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>Voici une s\u00e9rie d’articles sur un sujet qui me semble important: La gestion des performances au travers des “attentes”.<\/p>\n
<\/p>\n
Vous avez compris que l’on peut identifier et r\u00e9soudre un grand nombre de probl\u00e8mes de performances en s’int\u00e9ressant aux attentes observ\u00e9es sur une instance de bases de donn\u00e9es.<\/p>\n
<\/p>\n
<\/p>\n
Lorsqu’une requ\u00eate est ex\u00e9cut\u00e9e, on peut consid\u00e9rer qu’elle passe son temps \u00e0 attendre:<\/p>\n
On pourrait consid\u00e9rer que la requ\u00eate, \u00a0lorsque la t\u00e2che associ\u00e9e consomme du CPU, est en attente de “fin de traitement CPU”. Mais il est d’usage de dire que le temps pass\u00e9 dans le CPU n’est pas du temps attendu.<\/p>\n
<\/p>\n
On peut donc dire (en excluant pour l’instant le cas particulier du parall\u00e9lisme )\u00a0que le temps d’ex\u00e9cution d’une requ\u00eate correspond \u00e0 la somme du temps pass\u00e9 dans le CPU et du temps pass\u00e9 sur chaque attente.<\/strong><\/p>\n Donc en connaissant le temps pass\u00e9 sur chaque attente (on parle de “ventilation des postes d’attente”), il est possible de savoir o\u00f9 la requ\u00eate a pass\u00e9 plus de temps. Donc de savoir quoi optimiser .<\/p>\n Quelques exemples pour une requ\u00eate dont le temps d’ex\u00e9cution (entre le moment o\u00f9 l’utilisateur clique sur “Ex\u00e9cuter” et celui o\u00f9 l’application cliente lui rend la main) est de \u00a010 secondes:<\/p>\n En cherchant \u00e0 \u00e9liminer les attentes sur les verrous, on ne pourra gagner qu’une seconde, soit 10% du temps total d’ex\u00e9cution. Par contre, en s’int\u00e9ressant la la communication entre l’application et l’instance, on peut esp\u00e9rer gagner jusqu’\u00e0 60% de ce temps d’ex\u00e9cution<\/p>\n Il n’y a ici qu’en cherchant \u00e0 r\u00e9duire le temps pass\u00e9 \u00e0 lire les donn\u00e9es sur disque que l’on peut sensiblement r\u00e9duire le temps total d’ex\u00e9cution, et on peut esp\u00e9rer diviser par 10 cette dur\u00e9e ! Attention, on sait simplement que l’on attend “trop” sur la lecture des donn\u00e9es, pas si cette attente est due \u00e0 des disques trop lents ou \u00e0 des balayages d’objets trop volumineux. Il faudra n\u00e9cessairement pousser l’investigation pour savoir comment r\u00e9duire cette attente.<\/p>\n Sans surprise ici, c’est en cherchant \u00e0 r\u00e9duire la dur\u00e9e de la ou des demandes de verrous que l’on r\u00e9duira la temps total d’ex\u00e9cution de la requ\u00eate.<\/p>\n <\/p>\n En regardant \u00e0 un instant T l’ensemble des t\u00e2ches qui s’ex\u00e9cutent sur l’instance, en regardant pour chaque t\u00e2che le poste d’attente, on peut savoir s’il y a une \u00e9ventuelle contention sur l’instance, ou plus globalement conna\u00eetre le profile d’activit\u00e9 \u00e0 cet instant.<\/p>\n Si on observe par exemple 10 t\u00e2ches en attente de lib\u00e9ration d’un verrou pour 11 t\u00e2ches en tout, il s’agit clairement d’un probl\u00e8me de contention sur la concurrence d’acc\u00e8s<\/p>\n Si on observe 10 t\u00e2ches en attente de lecture de donn\u00e9es sur disque sur 11 t\u00e2ches en tout, les disques ne sont a priori pas adapt\u00e9s \u00e0 soutenir la demande faite par SQL Server.<\/p>\n <\/p>\n Disposer de ce type d’informations est crucial lorsqu’il s’agit d’identifier la cause d’une saturation d’instance, d’un ralentissement g\u00e9n\u00e9ral d’une application. Il permet aussi de savoir s’il peut \u00eatre int\u00e9ressant par exemple d’ajouter de la m\u00e9moire ou des CPUs \u00e0 une instance SQL Server…<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Le Moniteur d’Activit\u00e9 de Management Studio<\/a> donne un aper\u00e7u de la r\u00e9partition des attentes \u00e0 l’instant T. Ces attentes sont class\u00e9es par cat\u00e9gorie pour faciliter l’identification de contentions.<\/p>\n Les vues sys.dm_exec_requests<\/a>\u00a0et sys.dm_os_waiting_tasks<\/a> donnent l’attente actuelle des requ\u00eates en cours d’ex\u00e9cution, le temps depuis laquelle chaque requ\u00eate attend , et \u00e9ventuellement la requ\u00eate bloquante lorsque l’attente concerne un verrou. En agr\u00e9geant les donn\u00e9es de ces vues par type d’attente, on peut conna\u00eetre l’activit\u00e9 globale de l’instance \u00e0 l’instant T<\/p>\n La vue sys.dm_os_wait_stats<\/a> permet de conna\u00eetre la somme des attentes (temps total attendu et nombre de t\u00e2ches ayant attendu) sur l’instance, depuis son d\u00e9marrage ou depuis que les compteurs ont \u00e9t\u00e9 r\u00e9initialis\u00e9s (via l’ex\u00e9cution de\u00a0dbcc sqlperf(‘sys.dm_os_wait_stats’ clear)<\/em>)<\/p>\n <\/p>\n Attention, toutes les attentes remont\u00e9es dans les vues ci-dessus ne correspondent pas \u00e0 des attentes subies lors d’ex\u00e9cution de requ\u00eates !<\/p>\n Lors de consultation de ces vues, il convient de filtrer ces “fausses attentes”. Les filtres ci-dessous permettent de ne pas afficher la grande majorit\u00e9 de ces fausses attentes, en plus des types d’attentes qui n’ont jamais \u00e9t\u00e9 observ\u00e9s:<\/p>\n <\/p>\n <\/p>\n <\/p>\n Il existe plusieurs centaines d’attentes (plus de 700 pour SQL Server 2014<\/a>), les connaitre toutes rel\u00e8ve donc de l’impossible. Mais il est revanche possible de conna\u00eetre les grandes familles, de comprendre \u00e0 quels m\u00e9canismes de SQL Server elles correspondent, et donc de savoir comment les r\u00e9duire.<\/p>\n C’est ce que je vais tenter de d\u00e9velopper dans les quelques articles \u00e0 venir.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Voici une s\u00e9rie d’articles sur un sujet qui me semble important: La gestion des performances au travers des “attentes”. Que vous ayez assist\u00e9 \u00e0 l’une des pr\u00e9sentations de David Baffaleuf ou de moi-m\u00eame lors des journ\u00e9es SQL Server (\u00a0JSS2012,\u00a0JSS2013,JSS2014-1… Continuer la lecture \n
\n
\n
C\u00f4t\u00e9 instance<\/h3>\n
Mesurer les attentes<\/h2>\n
select * from sys.dm_os_wait_stats\r\nWHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE',\r\n'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT',\r\n'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',\r\n'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',\r\n'ONDEMAND_TASK_QUEUE', 'BROKER_EVENTHANDLER')\r\nand wait_type not like 'SLEEP%'\r\nand wait_time_ms>0<\/pre>\n\u00a0Comprendre et r\u00e9duire les attentes<\/h2>\n
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"