Courtier de service - Durée de vie de la conversation?

Question

Nous essayons d'obtenir un courtier de service travaillant dans notre environnement afin de résoudre un cas de rentabilisation. Je ne sais pas si le titre du message est un bon, mais ma question est ci-dessous. Mais ce n'est peut-être pas une bonne question, alors après c'est ce que nous faisons et pourquoi je pense que c'est la bonne question.

Combien de messages doivent être envoyés sur une conversation avant de mettre fin à la conversation?

Nous voulons utiliser un courtier de service afin de mettre à jour asynchroneusement une table de résultats. La table de résultats est aplatis et rapide. Nous avons des déclencheurs sur les tables de base qui envoient un message avec leur table et leur clé primaire. Nous avons trois files d'attente:

Faible latence - objectif est de 15 secondes à traiter. Il gère des éléments qui changent relatifs à un élément spécifique.
La file d'attente en vrac - L'objectif est de 5 minutes à traiter. Il gère lorsque quelque chose change qui affecte plusieurs centaines d'articles. Il éclate la liste des articles qui ont été affectés et les nourrissent à la file d'attente de latence faible différée
Faible latence différée - L'objectif est de 30 minutes à traiter. Cela traite des articles mais seulement de la file d'attente en vrac.

Fondamentalement, si les informations de client sont mises à jour; Cela affecte de nombreux produits afin d'être envoyé à la file d'attente en vrac pour un traitement plus lent. Cependant, si un produit est mis à jour, cela est envoyé à la file d'attente de latence faible.

Nous réutilisons des conversations semblables à la blog de Remus Rusanu http://rusanu.com/2007/04/25/2007/04/25/reUX-conversations/ , à l'exception que nous le faisons en fonction du module de la clé primaire. Cela a l'avantage latéral de l'aide dans la déplication de la clé primaire.

Nous réutilisons donc des conversations et nous sommes dans nos directives. Avec deux threads, j'ai pu brûler 125 messages/seconde (goutte artificielle de plusieurs milliers de messages), ce qui est plus que capable de suivre la production (EST. 15 messages/sec).

Cependant, le problème que nous rencontrons est qu'après une période de temps, ~ 4 heures ou 120 000 messages, nous avons commencé à voir des blocs et une hauteur de lutlement sur SysDesend et la table de file d'attente. Les serrures sont LCK_M_U et sont des serrures de clé. Parfois, la Hobt est résolue à SysDesend et à la Table de file d'attente spécifique (file d'attente_).

Nous avons un processus en place qui mettra en place des conversations après 24 heures ou 30 minutes d'inactivité déjà, afin que nous puissions simplement augmenter le temps avant le vélo de conversations.

Nous utilisons SQL 2016 Enterprise (13.0.4001.0)

Déclencher des incendies (envoyer à une latence faible ou en vrac)
Recherchez ou créez une poignée de conversation.
envoyer le message
Procédure activée de la file d'attente
Mettre à jour la table des résultats

Le processus de nettoyage fonctionne toutes les 10 minutes pour voir s'il y a des conversations inactives. S'il les trouve plus de trois fois de suite, il la marque comme inactive et termine les conversations.

S'il vous plaît laissez-moi savoir s'il y a des détails supplémentaires pouvant être bénéfiques. Je n'ai pas beaucoup d'expérience avec le courtier de service, donc je ne sais pas si nos messages/secs sont bas, élevés ou indifférents.

[~ # ~ ~] Mise à jour [~ # ~]

Nous avons donc essayé de nouveau aujourd'hui et avons rencontré le même problème. Nous avons changé la durée de vie de la conversation à 2 heures et cela n'avait aucun effet. Nous avons donc mis en œuvre la 150 truc; qui avait le même problème.

Des tonnes d'attente sur Envoyer une conversation, en attente de SysDesend. Quelqu'un a-t-il d'autres idées?

Mise à jour 2

Nous avons exécuté le test plus longtemps et pour l'une des périodes d'échantillonnage de 17 minutes, nous avons traité des messages 41K sur 4 poignées de conversation. Nous avons pu continuer à suivre, sauf vers la fin lorsque les serrures sur la table SysDesend et la table de file d'attente sont devenues trop longues et nous avons commencé à dériver derrière avant de l'arrêter. Nous ne semblons avoir aucun message de traitement de problèmes, sans que les choses entrent dans la file d'attente, nous pouvons les retirer et les traiter au moins 5 fois cette vitesse. Notre vitesse semble être limitée en fonction de l'ajout de messages.

Sur un test ultérieur, nous avons supprimé l'un des déclencheurs qui représentaient 80% des messages. Même avec cette charge beaucoup réduite, nous avons commencé à voir les mêmes attentes.

Mise à jour 3

Merci, Remus pour vos conseils (et merci d'avoir posté des articles de blog d'excellents blogs sur le sujet, ils ont joué un rôle déterminant pour arriver à ce point).

Nous l'avons retourné aujourd'hui et avons fait mieux (comme dans nous sommes allés plus longtemps avant de voir les attentes et encore plus longtemps avant que cela nous aillés). Donc, les détails.

Nous avons changé: * Augmentation du nombre de conversations entretenues par fil de 1: 1 à 2: 1. Fondamentalement, nous avons eu 8 poignées de conversation pour 4 threads.

consolidated La file d'attente en vrac (car un message entrant pourrait signifier des centaines de messages sortants) pour consolider en moins de messages plus importants.

Notes sur cette tentative:

désactiver la procédure d'activation de la file d'attente cible. Aucun changement de blocage (nous avons attendu 5 minutes) et les messages sont envoyés à Sys.Transmission_Quues.
suivi SYS.CONVERSATION_ENDPOINTS. Ce nombre est passé de 0 13k très rapidement, puis plus lentement se leva tout au long de la journée se terminant autour de 25k après environ 5 heures. Le blocage n'a pas commencé à se produire avant d'atteindre 16k +/-
Je suis allé dans le CAD et j'ai dirigé les commandes DBReindex pour les files d'attente, bien qu'à partir d'une requête, des registres fantômes n'ont jamais été au-dessus de 200 environ avant que le nettoyage ne soit arrivé et laissé tomber le compte à 0.
sysDesend et SysderCV avaient des comptes identiques de 24 932 lorsque j'ai terminé le test.
nous avons traité ~ 310k messages en 5 heures.

Nous sommes allés si longtemps avant que les choses ne soient tombées en morceaux que je pensais vraiment que nous le ferions cette fois. Demain, nous essaierons de forcer les messages à passer par le fil.

Jonathan Fite · Accepted Answer

Je sais que c'est une mauvaise forme pour répondre à votre propre question, mais je voulais la clôturer pour toute personne intéressée. Nous avons finalement réussi à résoudre le problème, ou au moins résoudre suffisamment de choses pour répondre à nos exigences. Je tiens à remercier tous ceux qui ont contribué des commentaires; Remus Rusanu et Kin alors qu'ils étaient très utiles.

Notre base de données est assez occupée et est en mode RCSI. Nous avons plusieurs (milliers) d'appareils mobiles qui mettent à jour leurs informations de localisation toutes les 45 secondes. Grâce à ces mises à jour, plusieurs tables reçoivent leurs informations mises à jour (une design médiocre, car j'aurais limité les informations volatiles à une seule table, puis la joignaient pour les résultats). Ces tables sont les mêmes que nous essayions de générer de manière asynchrone des informations de rapport pour plutôt que d'avoir les utilisateurs finaux vont directement contre les tables de base.

Nous avons initialement eu les déclencheurs faisant un curseur sur les enregistrements modifiés dans chaque instruction de mise à jour/insertion (aurait dû être une ligne dans la plupart des cas) et envoyez chaque clé principale dans un message au courtier de service. Inside Service Courtier, en particulier la file d'attente en vrac étant d'autres curseurs qui ont exécuté la procédure UPSERT pour le rapport (une exécution par clé primaire).

Qu'est-ce qui nous a enfin commencé à travailler:

Nous avons supprimé les curseurs et nous sommes installés sur l'envoi de messages plus importants. Encore un message par transaction utilisateur par table, mais nous envoyons maintenant des messages avec plus d'une clé primaire.
Le processeur en vrac envoie également de multiples clés par message, ce qui a réduit le nombre de conversations d'envoi qui se passaient en tant que messages mélangés à l'autre file d'attente, selon le cas.
La table la plus volatile (notre table de données de périphérique mobile) a eu des déclencheurs enlevés. Nous avons mis à jour la procédure UPSERT pour inclure les clés étrangères appropriées et nous nous adressons maintenant sur cette table lors de la récupération des résultats aux utilisateurs. Cette table a facilement contribué à 80% des messages que nous avons dû traiter en une journée.

Nous traitons ~ 1M messages par jour (sans la table mobile) et la vaste majorité (99% +) de nos messages sont traités dans notre objectif. Nous avons toujours les points de vue occasionnels, mais compte tenu de la nature rare de celle qu'elle est jugée acceptable.

Facteurs contributifs:

J'ai trouvé un bogue dans la procédure de nettoyage de conversation mentionné précédemment non plus de nettoyer les conversations de manière appropriée et de la fin prématurément. Ceci a maintenant abouti à notre compte SysDesend pour ne jamais avoir plus de quelques milliers (la plupart de cela vient d'utiliser le 150 tour).
Les curseurs dans les déclencheurs semblaient maintenir plus de verrouillage que prévu (même avec statique, avant_only). Suppression de ceux-ci semble avoir fabriqué les serrures que nous voyons sur Envoyer une conversation plus transitoire de nature (ou au moins les temps que nous voyons sont beaucoup plus bas).
Nous avons essentiellement exécuté deux solutions côte à côte (le backend de la solution de courtier de service (pour les tests sous charge de production)) et la solution actuelle (une requête terrible qui couvre de nombreuses tables).

En tant qu'enfonge latérale, cela a découvert un problème de nettoyage des enregistrements de fantômes et, alors qu'il ne figurait pas sur les tables de courtier de service (système ou file d'attente), il est assez répandu dans notre système et les symptômes se lèvent très bien avec notre "pas de cause claire" problèmes que nous expérimentons parfois. L'enquête est en cours à ce sujet, nous essayons de trouver les tables qui y contribuent et nous allons probablement simplement reconstruire régulièrement leurs indices.

Merci une fois de plus.