MSSQL 2008 R1 SP2 - Broker Waits [Résolu]

[jeeps64]

Bonjour

Nous avons d'après un utilisateur un probleme de perfs sur un serveur 2008 R1 SP2
Nous avons installé notre outil de monitoring dessus
Il nous remonte beaucoup d'attente sur les wait_type BROKER_RECEIVE_WAITFOR et BROKER_TRANSMITTER

Pour les Waits BROKER_RECEIVE_WAITFOR, nous avons les ordres suivants

Code :

WAITFOR(RECEIVE TOP (1) message_type_name, conversation_handle, cast(message_body AS XML) AS message_body FROM [SqlQueryNotificationService-b9fbf67f-f163-40aa-82b7-46b079daaa30]), TIMEOUT @p2;

Pour le second, je ne trappe pas les ordres SQL en rapport avec celui-ci

Je ne connais rien du tout au service broker
Savez-vous si on peut optimiser ou éviter ce phénomène ?

Merci
Jeep64

[mikedavem]

Ce type d'attente n'est pas vraiment significatif dans votre cas je pense. Vous avez des boucles WAITFOR qui attendent un certain temps avant de s'éxecuter ce qui n'est pas un problème en soi.

Savez-vous si on peut optimiser ou éviter ce phénomène ?

Oui en réduisant le temps d'attente ou en n'utilisant pas service broker

Nous avons d'après un utilisateur un probleme de perfs sur un serveur 2008 R1 SP2

Quel est votre problème de lenteur exactement ? Avez vous ciblé le problème exact avec votre utilisateur ?

++

[jeeps64]

Merci de tes réponses

Les utilisateurs se plaignent de lenteur de façon générale
Je suis entrain de faire un état des lieux du serveur question perfs
C'est la première fois que je voyais ce type d'attente. D’où mon post ; ))

Pour ce qui est de l'utilisation de Service Broker, nous tentons de l'interdire sur les nouvelles installations.

Jeeps64

[elsuket]

Bonjour,

Les attentes telles que BROKER_RECEIVE_WAITFOR, BROKER_EVENTHANDLER et BROKER_TO_FLUSH peuvent être éliminés par filtrage sur la DMV sys.dm_os_wait_stats.
D'ailleurs si vous regardez sa documentation, c'est ce que vous verrez.

Je crois donc que si vous l'éliminez, vous allez trouver la véritable source du problème

Pour ce qui est de l'utilisation de Service Broker, nous tentons de l'interdire sur les nouvelles installations.

C'est un peu brutal
Service Broker n'est pas réputé pour sa lenteur.

@++

[SQLpro]

Ce sont des boucles d'écoute de Service Broker et il est normal, comme toute boucle d'écoute, qu'elle durent indéfiniment;

Pour ce qui est de l'utilisation de Service Broker, nous tentons de l'interdire sur les nouvelles installations.

Pourquoi ? C'est stupide, c'est un mécanisme redoutablement efficace et par sa nature asynchrone il permet de lisser la charge. Ce n'est certainement pas cela qui pose problème !

Avant de commencer à tout tripatouiller et faire beaucoup plus de mal, il faut comprendre comment fonctionne un SGBDR comme SQL Server. Sinon vous allez à la catastrophe !

Lisez la série d'article que j'ai écrit sur l'optimisation de SQL Server : http://sqlpro.developpez.com/optimisation/

Décrivez nous le nombre et la taille de vos bases, et l'infra de votre serveur (RAM, CPU, DISQUE...)

A +

[jeeps64]

Merci de toutes ces réponses
Le but de l'article était de comprendre les types d'attente BROKER%
Vous avez répondu à mon attente en tout cas

@sqlpro
Mon discours d'interdire Service Broker était un peu extrême en effet
Sans doute par méconnaissance de ma part ; ))

Jeeps64