2. MONITORING SQL SERVER
Attentes & Performances
Sponsors Platinum
Edition 2012 – 10 et 11 décembre
3. Merci à nos Sponsors
Edition 2012 – 10 et 11 décembre
Rencontrez les dans l’espace partenaires
Sponsors Platinum
Sponsors Gold
Sponsors Silver
4. SPEAKERS
Benjamin VESAN – bvesan@capdata.fr
David BAFFALEUF - dbaffaleuf@capdata.fr
http://www.capdata.fr
http://blog.capdata.fr
@capdata_blog / @dbaffaleuf
Sponsors Platinum
Edition 2012 – 10 et 11 décembre
5. AGENDA
1. Introduction.
2. Qu’est-ce qu’une attente.
3. Les différents postes d’attente.
4. Démos
5. Des outils pour mesurer.
6. Notion de baseline.
7. Démos
Edition 2012 – 10 et 11 décembre
6. INTRODUCTION
• Lorsque le problème est défini par un ‘sentiment’ de
l’utilisateur:
• « C’est plus lent que la semaine dernière. »
• « Le problème vient de la base de données, c’est sûr. »
• « On n’a rien changé dans l’application ! »
• Pas d’indication ou de direction précise.
• Par où commencer ?
• Le matériel ? CPU, mémoire, disques ?
• Les requêtes ?
• L’applicatif ?
Edition 2012 – 10 et 11 décembre
7. CONSOMMATION DE RESSOURCES ?
• SQL Server utilise 90% de la mémoire disponible ?
• SQL Server utilise 80% de la CPU disponible ?
• SQL Server utilise 90% de temps d’occupation disque ?
Edition 2012 – 10 et 11 décembre
C’EST NORMAL !
• SQL Server est conçu pour occuper le terrain (CPU, mémoire,
disques).
• Comment distinguer l’utilisation optimale de la saturation ?
LES ATTENTES !
9. ATTENTES ET PERFORMANCES
• Le temps d'exécution d'une requête est la somme des
temps d'attente.
• La somme des attentes sur une même ressource permet
d'identifier une contention.
• Si le top des attentes indique une contention sur les
entrées/sorties, pas la peine de regarder les compteurs
CPU.
• Permet de ne pas perdre de temps à chercher le
problème où il n’est pas.
SYMPTÔME != PROBLEME
Edition 2012 – 10 et 11 décembre
10. QUELQUES RAPPELS
• SQLOS = planifie les tâches à exécuter, gère les files
d’attente, l’allocation mémoire, la surveillance (resource
monitor, deadlocks). Modèle coopératif (vs préemptif)
=> sys.dm_os_schedulers
• Tâche = unité de travail à exécuter (batch).
=> sys.dm_os_tasks
•Worker = objet supportant l’exécution d’une tâche.
=> sys.dm_os_workers
Edition 2012 – 10 et 11 décembre
11. EXECUTION D’UNE TACHE
Worker pool
Edition 2012 – 10 et 11 décembre
Runnable
Queue
(signal_wait
_time)
SQLOS
IO Waiter Timer Abort
Host
SELECT ...
task C
task B
task Y task X
task S
task T
Yield
task A
signal
Lock ? OK !
Resource
Queues
(resource_wait
_time)
12. VU D’EN HAUT
oCas simple mais …
oParallélisme ?
oNUMA ? + + Lazy writer
Edition 2012 – 10 et 11 décembre
13. LES DIFFERENTS ETATS D’UNE TACHE
Edition 2012 – 10 et 11 décembre
RUNNABLE
RUNNING
SUSPENDED
14. ATTENTES SIGNAL / RESOURCE
Signal_wait _time + Resource_wait_time = Total Attentes
Total Attentes + CPU Time = Temps de réponse
• Si rapport Signal / (Signal + Resource) élevé, alors
contention CPU.
• Si rapport Resource / (Signal + Resource) élevé, alors
contention sur les ressources.
• Vérifier le type de ressource sur lequel porte la contention
avec sys.dm_os_wait_stats.
Contention
CPU !!
Edition 2012 – 10 et 11 décembre
Contention
I/O, locks,
CXPACKET,
latches...
S/(S+R) R/(S+R)
15. DÉJÀ VU ?
Edition 2012 – 10 et 11 décembre
PAGEIOLATCH_EX
WRITELOG PAGELATCH_SH
CXPACKET
RESOURCE_SEMAPHORE
IO_COMPLETION
LCK_M_Sch
17. LCK_%
• Attente sur un verrou.
• Attention à la portée du verrou suivant le mode
d’isolation.
• Détection avec les Blocked Process Reports (SQL Trace /
Xevents)
EXECUTE SP_CONFIGURE 'Blocked Process Threshold',5;
GO
RECONFIGURE;
GO
Edition 2012 – 10 et 11 décembre
18. PAGELATCH_%, LATCH_%
• Mécanisme de protection de structures mémoire.
• LATCH != LOCK
• Type PAGE Latch: gestion de la concurrence d’accès
physique des pages de données / d’indexes dans le Buffer
Pool.
• Mais aussi problème de concurrence d’accès
PFS/GAM/SGAM dans tempdb (cf session VHP Christophe
/ Frédéric).
• Type NonPage Latch: protection des structures internes
de SQL Server (files d’attente, File Control Block,
metadonnées, etc…)
Edition 2012 – 10 et 11 décembre
19. PAGEIOLATCH_%
• Lorsqu’une tâche demande des pages qui ne sont pas
dans le Buffer Pool, une demande de lecture depuis le
disque est émise.
• La tâche ne bloque pas la CPU le temps que la lecture
se termine.
• Elle se met en attente sur PAGEIOLATCH.
• De nombreuses attentes sur PAGEIOLATCH indiquent une
contention au niveau du sous-système disque.
Edition 2012 – 10 et 11 décembre
20. RESOURCE_SEMAPHORE
• Quelques opérateurs physiques nécessitent une allocation
mémoire (Hash Join, Hash Aggregate, Sort, Exchange).
• S’il n’y a plus de mémoire disponible pour effectuer ces
actions, la tâche est mise en attente.
• Tuning de requêtes !
• Parfois mélange de requêtes à faible coût (OLTP) et
requêtes à fort coût (DWH). Les requêtes à fort coût sont
pénalisées car moins prioritaires sur l’acquisition de
mémoire.
• Utilisation du pool de ressource par défaut de Resource
Governor pour gérer les allocations / timeouts.
• DBCC MEMORYSTATUS /
sys.dm_exec_query_memory_grants
Edition 2012 – 10 et 11 décembre
21. IO_COMPLETION
• Lorsque la mémoire nécessaire pour un tri n’est pas
disponible, le tri sera réalisé partiellement sur disque
(tempdb) en utilisant des I/Os synchrones ( …) et
un algorithme Merge Sort.
• (re) Création d’index
Edition 2012 – 10 et 11 décembre
22. WRITELOG
COMMIT = écriture physique
• Temps de réponse du disque pour écrire une transaction
trop élevé.
• Sous système disque pas assez performant.
• Séparation fichiers DATA / LOG.
Edition 2012 – 10 et 11 décembre
23. ASYNC_IO_COMPLETION
• Attentes sur des I/Os asynchrones hors pages de données.
• Exemple: création de fichiers de bases de données, zéro-initialisation
des fichiers (journaux de transactions
toujours + données potentiellement).
Edition 2012 – 10 et 11 décembre
24. CXPACKET
• Indique simplement l’utilisation de parallélisme.
• Si pourcentage très élevé et paramétrage DOP par défaut, alors
voir pour réduire DOP (resource governor, use plan, hints ).
• Max DOP 8 ou max NUMA core per node cf
http://support.microsoft. com/kb/2023536.
• Sinon peut couvrir une autre cause racine (IOs). Rechercher
dans sys.dm_os_waiting_tasks la ligne qui n’attend pas
sur CXPACKET.
Edition 2012 – 10 et 11 décembre
FINISH
CXPACKET
25. POSTES D’ATTENTE A IGNORER
• …WHERE wait_type NOT IN ( 'CLR_SEMAPHORE',
'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE',
'SLEEP_TASK', 'SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH', 'WAITFOR',
'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH',
'XE_TIMER_EVENT', 'BROKER_TO_FLUSH',
'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT',
'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_
SEMAPHORE', … et un peu plus à chaque
release … :)
Edition 2012 – 10 et 11 décembre
27. DES OUTILS POUR MESURER
• DMO: sys.dm_os_wait_stats, sys.dm_os_waiting_tasks.
• Réinitialisables avec :
dbcc sqlperf(‘sys.dm_os_wait_stats’,clear)
• Xevents: trace system_health par défaut (ring buffer +
fichier depuis SQL Server 2012). Possibilité de tracer les
attentes d’une session en ‘Live’.
• Activity Monitor disponible avec SSMS.
• SQL Server Performance Dashboard
• Management Dataware House (MDW).
Disponibles en Standard et Enterprise Edition !
Edition 2012 – 10 et 11 décembre
28. SYS.DM_OS_WAIT_STATS
• wait_type: nom de l’évènement d’attente.
• waiting_tasks_count: nombre d’attentes sur cet
évènement depuis le dernier redémarrage.
• wait_time_ms: temps total d’attente sur cet évènement.
• max_wait_time_ms: temps maximum d’attente sur cet
évènement.
• signal_wait_time_ms: temps passé en runnable queue.
• A calculer en plus:
• Avg wait (ms) = wait_time_ms / waiting_tasks_count
• Avg Signal time (ms) = signal_wait_time / waiting_tasks_count
• Avg Resource time (ms) = (wait_time_ms – signal_wait_time) / waiting_tasks_count
Edition 2012 – 10 et 11 décembre
29. SYS.DM_OS_WAITING_TASKS
• 1 ligne par tâche en attente (attente en cours).
• Joindre avec sys.dm_exec_sessions et
is_user_process=1 pour n’avoir que les sessions
utilisateur.
• session_id / exec_context_id: identifiant du worker en
attente (même session_id si parallélisme).
• blocking_session_id / blocking_exec_context _id:
identifiant du worker source du blocage (origine des
attentes CXPACKET si parallélisme).
• resource_description: identifiant de la ressource
(exchangeEventid, lock + associatedObjectid,
dbid:fileid:pageid, etc…)
Edition 2012 – 10 et 11 décembre
30. EXTENDED EVENTS
• system_health: attentes de plus de 15 secondes sur un
latch, 30 secondes sur un lock, et plus de 5 secondes sur
une ressource externe (serveur lié, XP stored procedure,
unsafe CLR, COM, etc…).
• Depuis SQL Server 2012 persistée dans un fichier sur
disque.
• Possibilité de tracer les attentes pour une session ‘live’:
Edition 2012 – 10 et 11 décembre
34. BASELINE ET ATTENTES 1/2
• Suivre l’évolution des postes d’attente dans le temps:
• Permet de reconnaître les signes de « bonne santé » de
l’application.
• Permet de détecter une anomalie (IOs ? Parallélisme ?
Mémoire ?) qui n’était pas perçue auparavant.
• Quoi mesurer:
• La répartition des postes d’attente:
oPar classe (IO, CPU, mémoire, verrous…)
oPar type (encore plus précis)
Edition 2012 – 10 et 11 décembre
35. BASELINE ET ATTENTES 2/2
• Comment mesurer:
• Informations contenues dans MDW, mais pas de
possibilité de comparaison native.
• Outils du marché:
oQuest Foglight Performance Analysis.
oPrecise for SQL Server.
Edition 2012 – 10 et 11 décembre
BVE
- workspace memory in SQL Server:
wk memory comes form the BP, up to 75%
7 iterators concerned: HJ, HA, SORT, SORT (topN), and 3 exchange
ideal grant: amount of memory for all the iterators needs without any spill too disk.
computed using cardinality estimates (row count and row size)
iterators can share a part or all the wk memory grant (fractions)
sort / hash have build / execution phases.
Usually the build uses more memory than execution
memory fraction = memory can be used by the next iterator (freed from the build phase ?)
resource semaphore queues:
control how many threads are using memory at any given time
not enough memory ? wait on RESOURCE_SEMAPHORE
each resource pool= 2 resource semaphores
Importance = parameter in RG
- small RS: cost < 3 and grant size < 5Mb
|__ Low importance set: 1 queue
|__ Medium importance set: 1 queue
|__ High importance set: 1 queue
- large RS: everythg else
|__ Low importance set: 5 queues
|__ cost < 10 (queue_id = 0 in sys.dm_exec_query_memory_grants)
|__ 10 =< cost < 99 (queue_id = 1 in sys.dm_exec_query_memory_grants)
|__ 100 =< cost < 999 (queue_id = 2 in sys.dm_exec_query_memory_grants)
|__ 10000 =< cost < 9999 (queue_id = 3 in sys.dm_exec_query_memory_grants)
|__ cost > 10000 (queue_id = 4 in sys.dm_exec_query_memory_grants)
|__ Medium importance set: 5 queues
|__ High importance set: 5 queues
Smaller cost queries are prioritized over larger cost.
Ex: A large cost 10000+ query will have to wait until all the smaller cost queries are finished,and
it can only start when 150% of requested memory is available.
If the query times out (waiting 25x query cost in seconds with max 24Hrs, ou paramètre
query wait (s) ou request_memory_grant_timeout_sec in RG), its grant can be reduced to
the minimum required grant for the plan (=> and spill the remaining on disk), or if there
is enough memory it will run. If it can't be done, throw error 8645:
"A timeout occurred while waiting for memory resources to execute the query in resource
pool '%ls' (%ld). Rerun the query."
min memory per query (Kb) = 1Mb by default
DBCC MEMORYSTATUS:
- small query memory object (default)
- Query memory Objects (default) : used for large queries
or sys.dm_exec_query_resource_semaphores
or sys.dm_exexc_query_memory_grants
(small query memory object + Query memory Objects) / BP target = 75%
Total available grant for large queries = Query memory Objects (default)
Anything that spills to tempdb goes directly to the disk.
When Hash Match spills: ----------------------------------------------------------------------------
estimates on both input and probe sizes.
Grace hash algorithm => if grant is exceeded, HM sends sme buckets on disk
When a match is found during the probe phase and the bucket is on disk, the probe row goes on disk too
and is processed later. What is done at the end of the in-memory probe is that both the buckets and
the probe rows are read back into memory, and the probe phase goes back again.
If not all the buckets can be loaded, buckets will be re-written to disk again, this is called recursion.
If there is too much recursion, a bailout occurs. Remaining buckets and probe rows are joined using a
non optimized NLJ (not visible in execution plans, only visible using hash warning in SQL trace / xevent and one
eventclass / map is bailout).
When Sort spills: ---------------------------------------------------------------------------------
using quicksort algo begin sorting in memory. If memory grant is exceeded, the entire intermediate
sort will go to disk (different from HM) and the sort will be continued using merge sort algo.
use sort warning events (fire on each // thread)
When Exchange spills: -----------------------------------------------------------------------------
usage is DOP*2 buffers perf side (producer / consumer)
spilling when using merge exchange (gather / repartition)
Intra query // deadlock
Use exchange spill events
Spills are waiting on IO_COMPLETION, check internal object allocation (sys.dm_db_session_space_usage)
Note: varchar() are estimated at 50% at the size, nothing to do with the actual data size.
Try demos using parameter sniffing to show :
- RESOURCE_SEMAPHORE.
- IO_COMPLETION.
Or using a multistatement TVF used with a sort (because the sort is always estimated against 1 row
out o a TVF returning table like this)
BVE
DBA
DBA
BVE
BVE
DBA
Dernière date de clear:
Select wait_time_ms/1000/3600 as 'HOURS', wait_time_ms/1000/3600/24 as 'DAYS'
From sys.dm_os_wait_stats where wait_type = 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'
GO
BVE