Discussion :

[janlouk]

Bonjour à tous,

J'ai des lenteurs sur un serveur, et en utilisant un script de Brent Ozar un peu plus complet, je tombe sur PREEMPTIVE_XE_GETTARGETSTATE qui est en premier.

Voici ce que j'obtiens:



Malgré que je regarde ici, je ne comprends pas la signification et si c'est important : https://www.sqlskills.com/help/waits...ettargetstate/

Pour le WRITELOG, il attend pour écrire dans le log, ça vient surtout d'une lenteur du disque? Est-ce qu'un nombre élevé de VLF peut être à l'origine aussi?

Si vous avez une remarque sur les autres attentes dont je dois faire absolument attention, je suis preneur.

Merci beaucoup.

[mikedavem]

Hello,

PREEMPTIVE_XE_GETTARGETSTATE est un type d'attente que tu peux exclure de ton résultat global. En effet il se produit lorsqu'un thread bascule en mode préemptif pour récupérer l'état d'une cible de sessions d'événements étendues. Le thread est obligé dans ce cas de sortir d'un contexte du process sqlservr.exe pour avoir accès à l'état d'une cible comme par exemple vérifier l'accès à un ficher xel. Donc on peut considérer que ce type d'attente n'est pas vraiment représentatif d'un problème de performance.

Dans ton cas le temps moyen d'attente pour un WRITELOG reste correct (j'ai certains clients qui ont des valeurs bien plus élevées sans pour autant souffrir de problèmes de performance) et ne présage pas de problème lié au stockage vu de loin. Il peut simplement indiquer une importante activité transactionnelle avec beaucoup de transactions courtes concurrentes ou peut être un problème de fragmentation excessif causé par page splits (phénomène qui peut générer une quantité importante dans le journal lors des mises à jour de données).

Moi j'irai plus vite regarder du côté des attentes PAGEIOLATCH_xxx et LCK_xxx dont les temps moyens sont anormalement importants.
Tu peux avoir un problème de manque de mémoire ou un stockage ne répondant pas assez vite (même si pour l'hypothèse du stockage cela n'est à mon avis plus qu'un symptôme que le réel problème). Les LCK_xxx peuvent indiquent que l'acquisition des verrous prend du temps et cela peut être du à un manque d'index (scans au lieu de seek) ce qui pourrait par ailleurs être corréler aux attentes PAGEIOLATCH_xxx. Cela peut être aussi causé par des transactions trop longues avec peut être des requêtes longues à éxecuter (manque d'index? ) ou un mauvais niveau d'isolation de transactions.

Bref ce ne sont évidement ici que des pistes à explorer et vérifier

++

[janlouk]

Salut David,

Ok merci pour les explications, je garde ça précieusement et je regarderai plus tard car j'ai déjà d'autres priorités que ce serveur...

[janlouk]

Juste encore une info stp David, ici je remarque qu'SQL Server passe son temps à attendre des Lock, c'est du "uniquement" à un manque d'index? Sur cette DB de 100 GB, on a des blocked process une fois par semaine, qui bloque l'application complètement. L'owner de l'appli tue les sessions et ça repart. Mais je cherche à savoir ce qui fait ces blocked process. Donc j'ai fait un Xevent, que j'ai trouvé sur un article de Nicolas. Mais j'en profite pour voir les WAIT et je vois ça donc:

[mikedavem]

on a des blocked process une fois par semaine, qui bloque l'application complètement.

Le mieux est de regarder du côté de l'événement blocked process report qui te génère un rapport des processus bloqués au où la situation de blocage se produit.

Il faut ensuite exploiter ce rapport car tu as pas mal d'information de ce que côté - requêtes ou procédures stockées impliqués, sessions, ressources concernées, type de locks, niveau d'isolation de transaction etc ...)

Possible que ce soit un index manquant mais il faut le vérifier ..

++

[janlouk]

Ok merci, je n'utilise jamais XEvent, donc j'ai du pas mal chercher. Je peux laisser 2 semaines? Je sais que ma question est compliquée, mais est-ce gourmand en terme de consommation?