La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Les Webcasts Groupe des Utilisateurs SQL Server Juin 2013 – Query memory grants David Baffaleuf– CAPDATA MVP SQL Server.

Présentations similaires


Présentation au sujet: "Les Webcasts Groupe des Utilisateurs SQL Server Juin 2013 – Query memory grants David Baffaleuf– CAPDATA MVP SQL Server."— Transcription de la présentation:

1 Les Webcasts Groupe des Utilisateurs SQL Server Juin 2013 – Query memory grants David Baffaleuf– CAPDATA MVP SQL Server

2 David Baffaleuf Leader SGBD reconnu en France Conseil Service Formation DBA à distance Management dinfrastructures IT hétérogènes Support Management Technical Management Data Management Production Management

3 Query Memory Grants en 30 Comprendre quest-ce quun query memory grant Pourquoi ça peut être un problème Comment identifier Comment résoudre Démos ! Questions / réponses 30 chrono

4 Query Memory Grants en 30 De la mémoire pour une requête Plan Compilation QueryMemoryGrant Max 75% Buffer Pool

5 Query Memory Grants en 30 Les opérateurs concernés SORT HASH MATCH EXCHANGE

6 Query Memory Grants en 30 2 besoins évalués à la compilation : – Mémoire requise (minimum grant): minimum syndical pour supporter les opérateurs concernés. La requête ne peut pas commencer son exécution sans cette valeur (par défaut, min memory per query = 1Mb) – Mémoire additionnelle (ideal grant): nécessaire pour faire toute la passe (tri, hash) en mémoire. Pas obligatoire, pas garantie. Note: Pour optimiser les besoins, certains opérateurs peuvent partager des fractions de QMG. (F4 sur opérateur) Evaluation des besoins

7 Demandes mémoire contrôlées par des sémaphores. 2 sémaphores par pool RG: – Un pour les requêtes à faible coût ( cost < 3 && ideal grant < 5Mb) – Un pour les requêtes à coût plus élevé (tout le reste) 3 sets par sémaphore (paramètre RG), une ou plusieurs queues par set – LOW SET: pool RG de faible importance – MEDIUM SET: pool RG de moyenne importance – HIGH SET: pool RG de haute importance Les requêtes à plus faible coût sont prioritaires sur les requêtes au coût plus élevé. Arbitrage des QMG Query Memory Grants en 30

8 File dattente et sémaphores 1/2 RG POOL DEFAULT SELECT TOP(1000) * FROM Production.TransactionHistory ORDER BY ActualCost DESC OPTION (MAXDOP 1) GO

9 File dattente et sémaphores 2/2 RG POOL (DEFAULT) SMALL SEMAPHORE (cost < 3 && ideal grant < 5Mb) LARGE SEMAPHORE (tout le reste) LOW SETMEDIUM SETHIGH SET LOW SETMEDIUM SETHIGH SET Large RS, MEDIUM SET, qid=0 Query Memory Grants en 30 5 queues par SET en Large RS: -qid=0, cost < 10 -qid=1, 10<=cost < 99 -qid=2, 100<=cost < 999 -qid=3, 1000<=cost < qid=4, cost > qid=5, cost < 10 -qid=6, 10<=cost < 99 -qid=7, 100<=cost < 999 -qid=8, 1000<=cost < qid=9, cost > …

10 Query Memory Grants en 30 Une fois dans une des queues, la requête va devoir attendre que 150% de la mémoire demandée soir disponible, … … et quil ny ait plus dautres requêtes prioritaires. Les requêtes favorisées sont celles dont le coût est le plus faible et limportance la plus élevée. Lattente est comptabilisée sur RESOURCE_SEMAPHORE. Priorités et Attentes 1/ requêtes MEDIUM SET QID = 0 Cost < 10 => Prioritaires 1 requête MEDIUM SET QID = < Cost < 999 Attente sur RESOURCE_SEMAPHORE …

11 Query Memory Grants en 30 Par défaut, la requête va attendre jusquà atteindre un timeout, qui est égal à 25 fois le coût de la requête en secondes avec une limite de 24 heures (!!). Sinon paramètre instance query wait (s). Sinon request_memory_grant_timeout dans le pool RG. Lorsque le timeout est atteint: – Soit lideal grant peut être réduit à la valeur de minimum grant, et le reste sera stocké sur disque (tempdb). – Sil ny a plus assez de mémoire au runtime pour honorer le minimum, Erreur 8645: "A timeout occurred while waiting for memory resources to execute the query in resource pool '%ls' (%ld). Rerun the query." Priorités et Attentes 2/2

12 Query Memory Grants en 30 Ideal Grant = pas de garantie. Besoin évalué à la compilation et basé sur lestimation des cardinalités (nombre de lignes produites x taille de la ligne) en entrée de lopérateur. Au runtime, SQL Server peut naccorder quune partie de ce qui a été demandé en fonction de létat des ressources, le reste se fera sur disque en 1 ou plusieurs passes. Utilisation dentrées / sorties synchrones (IO_COMPLETION). Mélange requêtes à fort coût et faible coût (DSS vs OLTP) Pourquoi ça peut être un problème

13 Query Memory Grants en 30 Problème avec Hash match 1/2 ID_DEPT ID_DEPT DEPARTEMENT PROPALOUER HASHID_DEPT 0xFFE4301 0xFFE5302 0xFFE6303 0xFFE7304 0xFFE8305 Hashtable hash(ID_DEPT) BUILD (1)PROBE (2)

14 Query Memory Grants en 30 La phase de Build nécessite de réserver de la mémoire pour les N buckets créés (estimation des cardinalités). Les buckets qui ne tiennent pas en mémoire vont sur disque (tempdb). Les lignes de probe qui joignent des buckets sur disque vont sur disque (tempdb). Une fois que toutes les jointures sur les buckets en mémoire sont terminées, on va relire les buckets + lignes de probe sur disque. Si la seconde passe ne tient pas davantage en mémoire, certains couples buckets + probes sont réécrites sur disque (recursion). Trop de recursion => Hash bailout. On laisse tomber la table de hachage et la jointure est faite en utilisant un NLJ non optimisé. Visible avec SQL Trace : Hash Warning ou Xevent : hash_warning (map = bailout), et depuis SQL Server 2012 un avertissement dans lopérateur. Compteur perfmon: Workfiles created /sec Problème avec Hash match 2/2

15 Query Memory Grants en 30 Algoritme Quicksort trie en mémoire. Si le memory grant est dépassé, tout le tri va sur disque (tempdb) et utilise un algoritme merge sort moins efficace. Visible grâce à SQL Trace: Sort Warning ou Xevent : sort_warning, et depuis SQL Server 2012 un avertissement dans lopérateur. Techniquement ni worktable ni workfile. Problème avec Sort

16 Query Memory Grants en 30 Nécessite DOP*2 buffers par flux (producteur / consommateur). – Distribute: 1 flux en entrée + DOP flux en sortie. – Repartition: DOP flux en entrée + DOP flux en sortie. – Gather: DOP flux en entrée + 1 flux en sortie. La taille du buffer est déterminée en fonction de lestimation des cardinalités. Problème avec Exchange 1/2 DOP = 8 DOP*2 Buffers DOP*2 Buffers DOP*2 Buffers DOP*2 Buffers

17 Query Memory Grants en 30 Arrive rarement. Souvent visible sur un Merge Exchange (parallélisme + ORDER BY, MJ, Stream AGG) lorsque lordre doit être préservé. Lorsquun worker récupère plus de lignes que les autres, et que lopérateur Merge ne peut plus préserver lordre, lensemble des lignes en entrées vont sur disque (Intra-Query Parallel Deadlock) Visible grâce à SQL Trace: Exchange Spill Event ou Xevent : exchange_spill. Problème avec Exchange 2/ x

18 Query Memory Grants en 30 DBCC MEMORYSTATUS Small Query Memory Objects (RG Pool, en pages) Query Memory Objects (RG Pool, en pages) DMO: sys.dm_exec_query_resource_semaphores sys.dm_exec_query_memory_grants sys.dm_os_waiting_tasks (RESOURCE_SEMAPHORE) Évènements SQL Trace: Hash Warning Sort Warning Exchange Spill Event. Trace par défaut (v >= 2012) Évènements XEvents: hash_warning sort_warning exchange_spill. Comment détecter les problèmes de QMG

19 Query Memory Grants en 30 Indexation Réécriture des requêtes Gérer les priorités en utilisant les pools de ressource RG. Plus de mémoire… Comment résoudre les problèmes de QMG DEMOS

20 Query Memory Grants en 30 Des questions ?

21 Les Webcasts Groupe des Utilisateurs SQL Server GUSS.fr


Télécharger ppt "Les Webcasts Groupe des Utilisateurs SQL Server Juin 2013 – Query memory grants David Baffaleuf– CAPDATA MVP SQL Server."

Présentations similaires


Annonces Google