Question MSMQ très lent pour recevoir des messages


Nous avons une configuration d’environnement MSMQ assez importante qui a décidé aujourd’hui de s’arrêter.

(Tout est une machine virtuelle sous vSphere 4.0 Update 1)

Il existe 8 serveurs Web qui reçoivent les données des clients sur le net. MSMQ est installé sur ces ordinateurs et envoie simplement le message MSMQ au serveur MSMQ principal. Les messages sont actuellement empilés dans la file d'attente sortante. Ces machines sont Windows 2008 Web Edition avec 2 Go de RAM et 2 vCPU.

Nous avons un serveur MSMQ en cluster (Windows Cluster Server) qui reçoit les messages des 8 serveurs Web. Il n'y a pas de limite à la quantité de données pouvant être dans les files d'attente. Le disque dur est 50 Go, et il y a 46 Go d'espace libre. Ces machines sont Windows 2008 Enterprise Edition avec 8 Go de RAM et 4 vCPU. Auparavant, le cluster disposait de 2 vCPU mais la charge du processeur atteignait 100%. J'ai donc augmenté les deux nœuds du cluster Windows à 4 vCPU.

Il existe 4 serveurs d'applications qui lisent les messages des files d'attente et les traitent.

Normalement, tout fonctionne parfaitement, mais pas aujourd'hui.

Ce matin, tout se passe très lentement. Les 8 serveurs Web affichent actuellement jusqu'à 300 000 messages dans les files d'attente sortantes. Le serveur en cluster affiche actuellement plus d'un million de messages dans les files d'attente (certains ne dépassent pas 200 000).

Si je regarde perfmon sur les 8 serveurs Web, cela montre que j’ai en moyenne 2 messages envoyés par seconde. Si je regarde perfmon sur le cluster, il montre ~ 7 messages par seconde arrivent dans le cluster.

Les machines qui lisent ne reçoivent pas beaucoup de messages chacune. Les services les plus rapides reçoivent 10-12 messages par seconde, les plus lents affichent 0 ou 1.

Le seul changement récemment est que nous avons changé le nombre de serveurs Web frontaux de 4 à 8. Nous l'avons fait il y a environ 2 semaines sans problème. Mardi, nous les avons mis hors tension pour voir comment les 4 autres pourraient supporter la charge. Mercredi, nous avons rallumé les quatre nouvelles machines.

Le disque du cluster affiche des entrées / sorties très basses et aucune file d'attente.

Pour plus de sécurité, j'ai mis à jour PowerPath avec la version la plus récente, mais cela n'a pas aidé.

Les 8 serveurs Web se trouvent sur un vLAN et les serveurs du cluster et les serveurs d'applications sur un second vLAN. Il n'y a pas de pare-feu entre les vLAN.

Et il n'y a rien d'utile dans les journaux de l'application ou du système sur les machines.


8
2018-02-06 02:31


origine


Il s’avère que la lenteur de lecture de MSMQ était en réalité un problème d’application. Les services qui lisent dans la file d’accès vont ensuite dans un partage de fichiers. Le partage de fichiers a commencé à prendre de plus en plus de temps, ce qui a entraîné un ralentissement des services, des sauvegardes des files d'attente et un désordre grandissant. Apparemment, notre base d’utilisateurs a augmenté beaucoup plus rapidement que prévu et nous exploitons au maximum l’un des groupes RAID du réseau SAN qui héberge les partages de fichiers. Lundi, nous passerons une commande urgente pour plus d’espace SAN avec notre fournisseur. - mrdenny
Nous n'avons pas vu cette croissance de file d'attente à l'avance, car notre serveur de surveillance est un serveur Windows 2003 et les machines Windows 2003 ne peuvent pas surveiller les files d'attente MSMQ Windows 2008 en cluster à distance. Le serveur de surveillance est déjà prévu pour une mise à niveau en mars. <soupir> - mrdenny


Réponses:


Chaque fois que quelqu'un dit avoir plus d'un million de messages, les klaxons d'alarme se déclenchent! Les messages nécessitent une mémoire de noyau (pool paginé) à gérer. Si vous avez un si grand nombre de messages, vous pouvez épuiser ce qui est disponible sur le serveur en cluster. Le nombre optimal de messages dans une file d'attente est égal à zéro. En gros, assurez-vous que vous pouvez normalement traiter les messages plus rapidement qu'ils ne peuvent arriver.

Je recommanderais de fermer les serveurs Web et de traiter complètement l'arriéré de messages avant de les remettre en ligne.

Référence Point 4 de cet article de blog: http://blogs.msdn.com/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

À votre santé John Breakwell (MSFT)


4
2018-02-06 15:34



Je reçois un appel du service PSS à ce stade et j'attends qu'ils me rappellent maintenant. J'ai empêché les messages d'entrer dans la file d'attente sur les serveurs Web. Les files d'attente sortantes sur les serveurs Web sont toutes pleines à ce stade avec 1 Go d'informations chacune. Les files d'attente en cluster ont un total d'environ 4,5 millions de messages chacune. Normalement, nous gardons un très petit nombre de messages dans les files d'attente car nous traitons les données très rapidement. Quelque chose est arrivé (je ne sais pas quoi) et tout est allé en enfer. - mrdenny
John, merci d'avoir jeté un coup d'oeil pour moi. D'après le résultat de tmq, je suppose que c'est mon problème. Limites de pools (calculées approximativement, en Ko) Paged: limite de 307.200 utilisée pour 397% Non paged: limite de 262 144 utilisée pour 49% J'ai les files d'attente qui s'épuisent lentement pendant que j'attends que PSS me rappelle. Si vous êtes à Redmond lors du sommet MVP, faites-le-moi savoir, bières sur moi. - mrdenny
@ user34024 nous avons trouvé le problème initial, que j'ai mis dans un commentaire ci-dessus. Merci pour l'aide. - mrdenny


J'ai demandé à l'un de nos administrateurs système et il a dit que notre point magique était quatre serveurs Web qui atteignaient la boîte MSMQ sur des machines virtuelles, puis ils sont passés à une boîte matérielle à résoudre. Essayez également la capture de paquets pour voir ce qui se passe. Y at-il beaucoup d’authentification qui va également à AD? Avec le bavardage de MSMQ, vous devez limiter les chemins d'accès réseau et éventuellement le chemin d'authentification.

HTH, Mandrin.


1
2018-02-06 03:08



Ont-ils pu déterminer la cause exacte du ralentissement lorsque vous avez plus de 4 serveurs Web en conversation avec un seul serveur MSMQ? Le stockage est un stockage SAN direct sur iSCSI, il ne devrait donc pas y avoir de problème de stockage. Je vais essayer d'éteindre 4 des 8 serveurs Web et voir ce que je propose. Si je dois dire à mon patron d’acheter du nouveau matériel, je vais avoir besoin d’une sacrée bonne raison. - mrdenny
Juste le bavardage des messages. Ils ont également trouvé des configurations d’authentification manquantes. - SQLGuyChuck
Je suppose que je téléchargerai Wharshark et le placerai sur le serveur MSMQ pour voir ce que cela montre. Impossible de le mettre sur les serveurs Web, il se bloque après environ 30 secondes à cause de la charge du trafic réseau. - mrdenny
J'ai donc activé WireShark sur la machine, et je vois environ 3 secondes entre les messages du serveur Web que je surveille. Inutile de dire que ça n'a pas l'air bien. - mrdenny
nous avons trouvé le problème initial, que j'ai mis dans un commentaire ci-dessus. Merci pour l'aide. - mrdenny


En référence à votre commentaire sur le manque d’administration à distance, oui, ce n’est pas une bonne histoire avec MSMQ et les compteurs de performances. Pour tous ceux qui suivent le fil et veulent savoir quelles combinaisons de systèmes d’exploitation fonctionnent, consultez le blog de Motley Queue:

Compteurs de performance MSMQ 4.0 et clé de registre NetNameForPerfCounters http://blogs.msdn.com/motleyqueue/archive/2007/12/14/msmq-4-0-performance-counters-and-the-netnameforperfcounters-registry-key.aspx

À votre santé John Breakwell (MSFT)


1
2018-02-07 23:31