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

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/

http://blog.capdata.fr/

http://www.capdata.fr/

http://www.osmozium.com/

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


De la mémoire pour une requête

Plan

Compilation

Query MemoryGrant

Max 75% Buffer Pool


Les opérateurs concernésSORT HASH MATCH

EXCHANGE


• 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



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


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


• 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 …


• 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


• 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


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)


• 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


• 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


• 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


• 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


• 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


• 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


Des questions ?

Les Webcasts

Groupe des Utilisateurs SQL Server

GUSS.fr

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

Documents