![\"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>Il y a quelques ann\u00e9es nous avons commenc\u00e9 \u00e0 r\u00e9orienter nos efforts de d\u00e9veloppement de nos agents de supervision AllDB<\/a> vers l’identification des probl\u00e8mes de performance, parce que c’est finalement le fond de notre travail au quotidien, et que cela n\u00e9cessite non seulement des comp\u00e9tences, mais aussi des outils de trace et de suivi des requ\u00eates consommatrices. L’id\u00e9e \u00e9tait de pouvoir identifier visuellement et le plus simplement possible un point de contention, selon plusieurs crit\u00e8res et r\u00e9cup\u00e9rer suffisamment d’informations pour pouvoir rapidement commencer une analyse sans avoir \u00e0 se connecter \u00e0 l’environnement concern\u00e9. Ces concepts ont donn\u00e9 ce que nous avons appel\u00e9 par la suite le palmar\u00e8s de requ\u00eates<\/a>, et qui a \u00e9t\u00e9 int\u00e9gr\u00e9 \u00e0 tous nos agents, pour Oracle, SQL Server, MySQL, PostgreSQL et MongoDB. <\/p>\n Une raison suppl\u00e9mentaire nous a pouss\u00e9 dans cette direction : la volont\u00e9 galopante qu’ont les entreprises de migrer leurs bases de donn\u00e9es on-premise vers des services manag\u00e9s du cloud (GCP, Amazon RDS, Azure, et les autres). La cruelle r\u00e9alit\u00e9 est que l’on ne gagne pas toujours en performance \u00e0 passer dans le cloud. Et si les clouders vous vantent les m\u00e9rites de l’\u00e9lasticit\u00e9 du cloud, votre portefeuille lui n’est pas \u00e9lastique \u00e0 l’infini. Il vous faut des outils d’analyse et de compr\u00e9hension des probl\u00e8mes de performance pour pouvoir maintenir un contr\u00f4le FINOPS sur les p\u00e9rim\u00e8tres que vous avez d\u00e9ploy\u00e9, sinon c’est l’escalade, et sous la pression la tentation de toujours ajouter des ressources pour d\u00e9bloquer l’activit\u00e9. <\/p>\n Aujourd’hui je propose de pr\u00e9senter les fonctionnalit\u00e9s du palmar\u00e8s pour SQL Server, et nous partirons ensuite d’un cas concret d’incident anonymis\u00e9 pour voir comment on arrive avec un tel outil \u00e0 mettre le doigt rapidement sur la requ\u00eate SQL \u00e0 l’origine du probl\u00e8me. A noter que contrairement au Query Store, le palmar\u00e8s SQL Server est compatible \u00e0 partir de SQL Server 2012, en Standard comme en Enterprise Edition. <\/p>\n Lundi matin, une alerte arrive dans la supervision concernant un serveur dans notre p\u00e9rim\u00e8tre de support, ‘File System sous le seuil<\/em>‘, et malgr\u00e9 le positionnement de seuil qui nous permet souvent de r\u00e9agir avant qu’il ne soit trop tard, la saturation est d\u00e9j\u00e0 l\u00e0. On ne vit pas dans un monde parfait, et parfois toutes les s\u00e9curit\u00e9s mises en place ne suffisent pas, surtout quand on remplit 230Gb de volume en l’espace de quelques minutes. Il para\u00eet que la nature a horreur du vide : OK donc un traitement a rempli la base tempdb tr\u00e8s rapidement et tr\u00e8s massivement, ce qui a provoqu\u00e9 une saturation de l’espace disque et une interruption de certains services. <\/p>\n Le palmar\u00e8s AllDB pour SQL Server propose de regarder le probl\u00e8me de performance selon plusieurs angles diff\u00e9rents: – Recherche<\/strong> : comme on historise tout (plans, op\u00e9rateurs, objets, requ\u00eates, advisors…) on peut faire une recherche ensuite sur tous ces crit\u00e8res et retrouver dans quelles sections ils sont apparus. <\/p>\n Parmi les nombreuses causes qui peuvent \u00eatre \u00e0 l’origine d’un remplissage de tempdb, il y a notamment le risque d’erreur d’estimation des cardinalit\u00e9s dans un plan qui peut conduire \u00e0 sous-\u00e9valuer le besoin en m\u00e9moire (aka <\/em>Query Memory Grants<\/a>). SQL Server aura besoin d’allouer de la m\u00e9moire \u00e0 l’ex\u00e9cution d’une requ\u00eate pour g\u00e9rer les tris, op\u00e9rateurs de parall\u00e9lisme ou op\u00e9rateurs Hash (Hash Match, Hash Join). S’il se trompe sur son estimation de lignes, il va demander, disons 100Mb parce qu’il s’attend \u00e0 trier 1000 lignes, mais en r\u00e9alit\u00e9 il est possible qu’il doive trier 10 millions de lignes. <\/p>\n Dans ce cas de figure il a demand\u00e9 trop peu de m\u00e9moire au moment de la compilation de son plan, et va devoir r\u00e9clamer une rallonge \u00e0 SQL Server au moment de l’ex\u00e9cution, qui ne pourra pas forc\u00e9ment lui \u00eatre octroy\u00e9e. Au final c’est tempdb qui sera mise \u00e0 contribution plut\u00f4t qu’un espace pris dans le buffer pool, avec les cons\u00e9quences sur la performance que l’on imagine …<\/p>\n Dans le palmar\u00e8s on peut rechercher les requ\u00eates qui ont n\u00e9cessit\u00e9 le plus de query memory grants, sur la p\u00e9riode de l’incident (palmar\u00e8s par ‘Allocation m\u00e9moire<\/em>‘):<\/p>\n Si on s’int\u00e9resse de plus pr\u00e8s aux d\u00e9tails de cette requ\u00eate (cliquer sur l’image pour voir les d\u00e9tails<\/em>):<\/p>\n Et tout \u00e7a sans avoir \u00e0 se connecter sur le serveur, d\u00e9pouiller les DMV, extraire le plan, sortir les cardinalit\u00e9s de la table, etc… <\/p>\n Conclusion : <\/strong>Gr\u00e2ce au palmar\u00e8s j’ai donn\u00e9 un pronostic au t\u00e9l\u00e9phone \u00e0 mon client en 10 minutes, l\u00e0 o\u00f9 il m’aurait fallu une bonne heure sans cet outil. <\/p>\n Si vous \u00eates \u00e9diteur, cet outil peut \u00e9galement vous aider \u00e0 mieux appr\u00e9hender la performance des requ\u00eates que vous d\u00e9veloppez. Alors si vous voulez une d\u00e9mo du palmar\u00e8s, n’h\u00e9sitez pas et contactez-nous<\/a> !!<\/p>\n A tr\u00e8s bient\u00f4t alors ? Il y a quelques ann\u00e9es nous avons commenc\u00e9 \u00e0 r\u00e9orienter nos efforts de d\u00e9veloppement de nos agents de supervision AllDB vers l’identification des probl\u00e8mes de performance, parce que c’est finalement le fond de notre travail au quotidien, et que cela… Continuer la lecture Le sympt\u00f4me :<\/h2>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm1-1.png\")
<\/a>
\nRapide corr\u00e9lation pour associer cette surconsommation d’espace \u00e0 une utilisation massive d’espace disque dans tempdb (cliquer pour agrandir<\/em>):
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm2.png\")
<\/a><\/p>\n-> Enter the ‘palmar\u00e8s<\/em>‘ :<\/h2>\n
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm3.png\")
<\/a>
\n– Palmar\u00e8s SQL<\/strong> : va rechercher les requ\u00eates normalis\u00e9es (c’est \u00e0 dire les requ\u00eates ‘semblables’, sans la partie litt\u00e9rale des arguments de recherche par exemple) qui auront eu le plus d’impact selon un crit\u00e8re (CPU, m\u00e9moire, lectures disques, temps d’ex\u00e9cution total, etc…) et sur une p\u00e9riode donn\u00e9e. Chaque histogramme empil\u00e9 repr\u00e9sente une unit\u00e9 de temps, et chaque fraction de cet histogramme une requ\u00eate (cliquer pour agrandir<\/em>):
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm8.png\")
<\/a>
\n– Ad-Hoc SQL<\/strong> : va simplement remonter le top 10 des requ\u00eates adhoc (donc non normalis\u00e9es) par clich\u00e9 et par crit\u00e8re (CPU, lectures disques, lectures logiques) :
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm9-1.png\")
<\/a>
\n– Tables & Indexes<\/strong>: prend une photo du buffer pool et cartographie son contenu (bases, tables, indexes) et l’\u00e9volution au cours du temps:
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm10.png\")
<\/a>
\nDans une autre vue, il calcule aussi un palmar\u00e8s mais des objets cette fois, en lecture ou en \u00e9criture, et l\u00e0 aussi sous la forme d’histogrammes empil\u00e9s:
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm11.png\")
<\/a>
\n– Plans d’ex\u00e9cution<\/strong> : aborde le probl\u00e8me par les plans: quels sont les plans les plus co\u00fbteux ?
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm12.png\")
<\/a>
\nQuelles sont les pr\u00e9conisations de placement d’index ?
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/plan14.png\")
<\/a>
\nDe quelle mani\u00e8re une m\u00eame requ\u00eate peut utiliser diff\u00e9rents plans et ainsi mettre en \u00e9vidence les variations de performance en passant d’un plan \u00e0 l’autre ?
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm13.png\")
<\/a>
\nSur la s\u00e9lection d’une requ\u00eate, on peut visualiser les diff\u00e9rents plans qu’elle a utilis\u00e9, quels sont les plus performants:
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm15.png\")
<\/a><\/p>\nPour revenir \u00e0 notre probl\u00e8me de tempdb…<\/h2>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm4-1.png\")
<\/a>
\nFacile de rep\u00e9rer la requ\u00eate qui d\u00e9passe du lot sur 24 heures, juste \u00e0 l’heure de notre remplissage, avec un superbe 619Gb de query memory grants cumul\u00e9s certes et on le verra plus loin sur 556 ex\u00e9cutions, mais quand m\u00eame. Le buffer pool disposant de 117Gb de m\u00e9moire, il y a des chances pour qu’il ne puisse pas servir la totalit\u00e9 de ce qui est demand\u00e9, et donc le reste va aller dans tempdb sous la forme de stockage interne (internal allocation<\/em>). <\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm5.png\")
<\/a>
\n… et que l’on ouvre son plan sous SQL Sentry Plan Explorer<\/a> :
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm6.png\")
<\/a>
\nOn voit en bas \u00e0 droite que la table lue est sans index cluster, avec 27% d’impact et un magnifique warning sur des I\/Os r\u00e9siduels qui pourraient r\u00e9sulter du fait que la table doit \u00eatre lue en int\u00e9gralit\u00e9 (soit 6.6 millions de lignes r\u00e9ellement et pas 1 million comme estim\u00e9):
\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/03\/palm7.png\")
<\/a>
\nDans ce cas, il existe un index unique sur le pr\u00e9dicat mais non clusteris\u00e9. Le manque de couverture poussera l’optimiseur \u00e0 faire un fullscan de la table plut\u00f4t qu’un Index Seek accompagn\u00e9 de RID lookups ensuite. La cr\u00e9ation d’un index cluster unique devrait permettre de couvrir toutes les colonnes demand\u00e9es et d’\u00e9viter ensuite d’avoir \u00e0 faire des jointures Merge en cascade, \u00e0 chaque fois n\u00e9cessitant des tris, ce qui conduit \u00e0 l’\u00e9normissime consommation de Query Memory Grants in fine<\/em>. <\/p>\n
\n~David <\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"