Upload
rousel-gay
View
109
Download
1
Embed Size (px)
Citation preview
Les Webcasts
Groupe des Utilisateurs SQL Server
Juin 2013 – Query memory grantsDavid Baffaleuf– CAPDATA
MVP SQL Server
David Baffaleufhttp://blog.capdata.fr @dbaffaleuf
Leader SGBD reconnu en Francewww.capdata.fr Conseil Service Formation DBA à distance
Management d’infrastructures IT hétérogèneswww.osmozium.com Support Management Technical Management Data Management Production Management
http://www.youtube.com/user/CapdataTV/
Query Memory Grants en 30’
• Comprendre qu’est-ce qu’un query memory grant• Pourquoi ça peut être un problème• Comment identifier• Comment résoudre• Démos !• Questions / réponses
30 ‘ chrono
Query Memory Grants en 30’
De la mémoire pour une requête
Plan
Compilation
Query MemoryGrant
Max 75% Buffer Pool
Query Memory Grants en 30’
Les opérateurs concernésSORT HASH MATCH
EXCHANGE
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
• 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’
Query Memory Grants en 30’
File d’attente et sémaphores 1/2
RG POOL
DEFAULT
SELECT TOP(1000)* FROM Production.TransactionHistoryORDER BY ActualCost DESCOPTION (MAXDOP 1)GO
File d’attente et sémaphores 2/2RG POOL (DEFAULT)
SMALL SEMAPHORE (cost < 3 && ideal grant < 5Mb)
LARGE SEMAPHORE(tout le reste)
LOW SET MEDIUM SET HIGH SET
LOW SET MEDIUM SET HIGH 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 < 9999- qid=4, cost > 10000
LOW - qid=5, cost < 10- qid=6, 10<=cost < 99- qid=7, 100<=cost < 999- qid=8, 1000<=cost < 9999- qid=9, cost > 10000 …
MED
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 qu’il n’y ait plus d’autres requêtes prioritaires.• Les requêtes favorisées sont celles dont le coût est le plus
faible et l’importance la plus élevée. • L’attente est comptabilisée sur RESOURCE_SEMAPHORE.
Priorités et Attentes 1/2
100+ requêtesMEDIUM SET
QID = 0Cost < 10
=> Prioritaires
1 requête MEDIUM SETQID = 2
100 < Cost < 999Attente sur
RESOURCE_SEMAPHORE …
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 l’ideal grant peut être réduit à la valeur de minimum grant, et le reste sera stocké sur disque (tempdb).
– S’il n’y 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
Query Memory Grants en 30’
• Ideal Grant = pas de garantie.• Besoin évalué à la compilation et basé sur l’estimation des
cardinalités (nombre de lignes produites x taille de la ligne) en entrée de l’opérateur.
• Au runtime, SQL Server peut n’accorder qu’une 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 d’entré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
Query Memory Grants en 30’
Problème avec Hash match 1/2
ID_DEPT
33
89
75
29
44
ID_DEPT
01
02
03
04
05
DEPARTEMENT PROPALOUERHASH ID_DEPT
0xFFE43 01
0xFFE53 02
0xFFE63 03
0xFFE73 04
0xFFE83 05
Hashtable
hash(ID_DEPT)
BUILD (1) PROBE (2)
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 l’opérateur. • Compteur perfmon: Workfiles created /sec
Problème avec Hash match 2/2
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 l’opérateur.
• Techniquement ni worktable ni workfile.
Problème avec Sort
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 l’estimation des cardinalités .
Problème avec Exchange 1/2
DOP = 8DOP*2 Buffers
DOP*2 Buffers
DOP*2 Buffers
DOP*2 Buffers
Query Memory Grants en 30’
• Arrive rarement. Souvent visible sur un Merge Exchange (parallélisme + ORDER BY, MJ, Stream AGG) lorsque l’ordre doit être préservé.
• Lorsqu’un worker récupère plus de lignes que les autres, et que l’opérateur Merge ne peut plus préserver l’ordre, l’ensemble 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/2
1 2 3 5 6 7 8 9 104
1 3 5 6 7 84 10
2 9
1 2 3 x
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
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
Query Memory Grants en 30’
Des questions ?
Les Webcasts
Groupe des Utilisateurs SQL Server
GUSS.fr