MSMQ très lent à recevoir des messages

Nous avons une configuration d'environnement MSMQ assez grande 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 des données des clients sur le net. Ces machines ont toutes MSMQ installé et envoient 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 sur la quantité de données pouvant être dans les files d'attente. Le disque dur est de 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. Le cluster avait auparavant 2 processeurs virtuels, mais la charge du processeur atteignait 100%, j'ai donc augmenté les deux nœuds du cluster Windows à 4 processeurs virtuels.

Il y a 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 déroule très lentement. Les 8 serveurs Web affichent actuellement jusqu'à 300 000 messages placés 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 ko).

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

Les machines qui font la lecture 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 pouvaient gérer la charge. Mercredi, nous avons rallumé les quatre nouvelles machines.

Le disque sur le cluster affiche un E / S très faible et aucune file d'attente.

Pour être sûr, j'ai mis à jour PowerPath vers la dernière version, mais cela n'a aidé personne.

Les 8 serveurs Web sont sur un vLAN, et les serveurs en cluster et les serveurs d'applications sont sur un deuxième vLAN. Il n'y a pas de pare-feu entre les vLAN.

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

performance msmq

— mrdenny
source

Il s'avère que la cause de la lecture lente de MSMQ était en fait un problème d'application. Les services qui lisent à partir de la file d'attente vont ensuite à des trucs sur un partage de fichiers. Le partage de fichiers a commencé à prendre de plus en plus de temps, ce qui a ralenti les services, ce qui a entraîné la sauvegarde des files d'attente, et nous avons maintenant un gâchis. Apparemment, notre base d'utilisateurs a augmenté beaucoup plus rapidement que prévu et nous maximisons l'un des groupes RAID sur le 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 parce que notre serveur de surveillance est un serveur Windows 2003 et que la machine Windows 2003 ne peut pas surveiller à distance les files d'attente MSMQ Windows 2008 en cluster. Le serveur de surveillance est déjà prévu pour une mise à niveau en mars. <sigh>

— 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 la gestion de la mémoire du noyau (pool paginé). Si vous avez un si grand nombre de messages, vous épuisez peut-être ce qui est disponible sur le serveur en cluster. Un nombre optimal pour le nombre de messages dans une file d'attente est zéro - assurez-vous que vous pouvez normalement traiter les messages plus rapidement qu'ils ne peuvent arriver.

Je recommanderais d'arrêter les serveurs Web et de traiter complètement l'arriéré des messages avant de les remettre en ligne.

Élément de référence 4 de ce billet de blog: http://blogs.msdn.com/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

Vive John Breakwell (MSFT)

J'ai un appel à PSS à ce stade, et j'attends qu'ils me rappellent maintenant. J'ai empêché les messages de circuler dans la file d'attente sur les serveurs Web. Les files d'attente sortantes sur les serveurs Web sont toutes saturées à 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 nombre très faible de messages dans les files d'attente car nous obtenons le traitement des 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'œil pour moi. Sur la base de la sortie de tmq, je suppose que c'est mon problème. Limitations des pools (calculées approximativement, en Ko) Paginé: limite 307 200 utilisé pour 397% Non paginé: limite 262 144 utilisé pour 49% J'ai les files d'attente ralentissant le drainage pendant que j'attends que PSS me rappelle. Si vous êtes à Redmond pendant le MVP Summit, 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 de 4 serveurs Web max. Essayez également la capture de paquets pour voir ce qui se passe. Y a-t-il beaucoup dans l'authentification pour AD aussi? Avec la façon dont MSMQ est bavard, vous devez limiter les chemins réseau et éventuellement le chemin d'authentification.

HTH, Chuck.

— SQLGuyChuck
source

Ont-ils pu déterminer la cause exacte du ralentissement lorsque plus de 4 serveurs Web parlent à un seul serveur MSMQ? Le stockage est un stockage SAN direct sur iSCSI, ce ne devrait donc pas être un 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, j'aurai 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 vais télécharger Wheelshark et le mettre sur le serveur MSMQ et voir ce qu'il montre. Impossible de le mettre sur les serveurs Web, il se bloque après environ 30 secondes en raison de la charge du trafic réseau.

— mrdenny

J'ai donc lancé WireShark sur la machine, et je vois environ 3 secondes entre les messages du seul serveur Web que je surveille. Inutile de dire que cela ne semble pas bon.

— mrdenny

nous avons trouvé le problème initial, que j'ai mis dans un commentaire ci-dessus. Merci pour l'aide.

— mrdenny

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

Compteurs de performances 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

Vive John Breakwell (MSFT)