MSMQ empfängt Nachrichten nur sehr langsam

Wir haben eine ziemlich große MSMQ-Umgebung eingerichtet, die heute beschlossen hat, zum Stillstand zu kommen.

(Alles ist eine VM unter vSphere 4.0 Update 1)

Es gibt 8 Webserver, die Daten von Clients im Internet empfangen. Auf diesen Computern ist MSMQ installiert, und die MSMQ-Nachricht wird einfach an den MSMQ-Hauptserver gesendet. Nachrichten werden derzeit in der ausgehenden Warteschlange gestapelt. Diese Computer sind Windows 2008 Web Edition mit 2 GB RAM und 2 vCPUs.

Wir haben einen Clustered MSMQ-Server (Windows Cluster Server), der die Nachrichten von den 8 Webservern erhält. Die Datenmenge in den Warteschlangen ist unbegrenzt. Die Festplatte ist 50 Gigs und es gibt 46 Gigs freien Speicherplatz. Diese Computer sind Windows 2008 Enterprise Edition mit 8 GB RAM und 4 vCPUs. Der Cluster hatte früher 2 vCPUs, aber die CPU-Auslastung lag bei 100%. Daher habe ich beide Knoten des Windows-Clusters auf 4 vCPUs erhöht.

Es gibt 4 App-Server, die die Nachrichten aus den Warteschlangen lesen und verarbeiten.

Normalerweise funktioniert das alles perfekt, aber heute nicht mehr.

Heute morgen läuft alles sehr langsam. Auf den 8 Webservern werden derzeit bis zu 300.000 Nachrichten in den ausgehenden Warteschlangen angezeigt. Der Cluster-Server zeigt derzeit über eine Million Nachrichten in den Warteschlangen an (einige sind nur 200 KB groß).

Wenn ich mir perfmon auf den 8 Webservern ansehe, zeigt dies, dass ich durchschnittlich 2 Nachrichten pro Sekunde sende. Wenn ich mir perfmon im Cluster ansehe, werden ~ 7 Nachrichten pro Sekunde im Cluster angezeigt.

Die Maschinen, die das Lesen durchführen, erhalten nicht jeweils viele Nachrichten. Die schnellsten Dienste erhalten 10-12 Nachrichten pro Sekunde, die langsamsten 0 oder 1.

Die einzige Änderung in letzter Zeit ist, dass wir die Anzahl der Front-End-Webserver von 4 auf 8 geändert haben. Wir haben dies vor ungefähr 2 Wochen ohne Probleme getan. Am Dienstag haben wir sie ausgeschaltet, um zu sehen, wie die restlichen 4 mit der Last umgehen können. Am Mittwoch haben wir die vier neueren Maschinen wieder eingeschaltet.

Die Festplatte im Cluster zeigt sehr niedrige E / A und keine Warteschlangen.

Um sicher zu gehen, habe ich PowerPath auf die neueste Version aktualisiert, aber das hat keinem geholfen.

Die 8 Webserver befinden sich in einem vLAN, und die Cluster-Server und die App-Server befinden sich in einem zweiten vLAN. Es gibt keine Firewalls zwischen den vLANs.

Und es gibt nichts Nützliches in den Anwendungs- oder Systemprotokollen auf einem der Computer.

performance msmq

— mrdenny
quelle

Es stellt sich heraus, dass die Ursache für das langsame Lesen von MSMQ tatsächlich ein Anwendungsproblem war. Die Dienste, die aus der Warteschlange lesen, werden dann auf einer Dateifreigabe gespeichert. Die Dateifreigabe dauerte immer länger, was dazu führte, dass die Dienste langsamer ausgeführt wurden, was dazu führte, dass die Warteschlangen gesichert wurden, und jetzt haben wir ein Durcheinander. Anscheinend ist unsere Benutzerbasis viel schneller als geplant gewachsen und wir maximieren eine der RAID-Gruppen im SAN, in denen die Dateifreigaben gehostet werden. Montag werden wir bei unserem Lieferanten eine Eilbestellung für mehr SAN-Speicherplatz aufgeben.

— Mrdenny

Wir haben dieses Warteschlangenwachstum nicht im Voraus gesehen, da unser Überwachungsserver ein Windows 2003-Server ist und Windows 2003-Computer Clustered Windows 2008 MSMQ-Warteschlangen nicht remote überwachen können. Der Überwachungsserver ist bereits für ein Upgrade im März geplant. <

— seufz

Antworten:

Immer wenn jemand sagt, er habe über eine Million Nachrichten, gehen die Alarmklaxone aus! Für Nachrichten muss der Kernel-Speicher (Paged Pool) verwaltet werden. Wenn Sie so viele Nachrichten haben, erschöpfen Sie möglicherweise die verfügbaren Informationen auf dem Clusterserver. Eine optimale Anzahl für die Anzahl der Nachrichten in einer Warteschlange ist Null. Stellen Sie im Grunde sicher, dass Sie Nachrichten normalerweise schneller verarbeiten können, als sie ankommen können.

Ich würde empfehlen, die Webserver herunterzufahren und den Rückstand an Nachrichten vollständig zu verarbeiten, bevor sie wieder online geschaltet werden.

Referenzpunkt 4 dieses Blogposts: http://blogs.msdn.com/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

Prost John Breakwell (MSFT)

Ich habe zu diesem Zeitpunkt einen Anruf bei PSS und warte darauf, dass sie mich jetzt zurückrufen. Ich habe verhindert, dass Nachrichten in die Warteschlange auf den Webservern fließen. Die ausgehenden Warteschlangen auf den Webservern sind zu diesem Zeitpunkt alle mit jeweils 1 Gig an Informationen voll. Die Clustered Queues enthalten insgesamt jeweils etwa 4,5 Millionen Nachrichten. Normalerweise halten wir eine sehr geringe Anzahl von Nachrichten in den Warteschlangen, da die Daten sehr schnell verarbeitet werden. Etwas ist passiert (nicht sicher was) und alles ging zur Hölle.

— Mrdenny

John, danke, dass du einen Blick auf mich geworfen hast. Basierend auf der Ausgabe von tmq denke ich, dass das mein Problem ist. Poolbeschränkungen (ungefähr berechnet in KB) Ausgelagert: Limit 307.200 für 397% verwendet Nicht ausgelagert: Limit 262.144 für 49% verwendet Ich habe die Warteschlangen langsamer, während ich darauf warte, dass PSS mich zurückruft. Wenn Sie während des MVP-Gipfels in Redmond sind, lassen Sie es mich wissen, Bier auf mich.

— Mrdenny

@ user34024 Wir haben das anfängliche Problem gefunden, das ich oben in einen Kommentar eingefügt habe. Danke für die Hilfe.

— Mrdenny

Ich fragte einen unserer Systemadministratoren und er sagte, unser magischer Punkt sei, dass maximal 4 Webserver die MSMQ-Box auf virtuellen Maschinen treffen, und dann gingen sie zur Lösung in die Hardware-Box. Versuchen Sie auch die Paketerfassung, um zu sehen, was los ist. Gibt es auch viel Authentifizierung für AD? Mit wie gesprächig MSMQ ist, müssen Sie Netzwerkpfade und möglicherweise Authentifizierungspfad begrenzen.

HTH, Chuck.

— SQLGuyChuck
quelle

Konnten sie herausfinden, was genau die Verlangsamung verursacht hat, wenn mehr als 4 Webserver mit einem einzelnen MSMQ-Server kommunizieren? Der Speicher ist ein direkter SAN-Speicher über iSCSI, daher sollte es sich nicht um ein Speicherproblem handeln. Ich werde versuchen, 4 der 8 Webserver herunterzufahren und zu sehen, was mir einfällt. Wenn ich meinem Chef sagen muss, er solle neue Hardware kaufen, brauche ich einen verdammt guten Grund.

— Mrdenny

Nur das Geschwätz der Nachrichten. Sie fanden auch einige Konfigurationen für Authentifizierungsfehler.

— SQLGuyChuck

Ich denke, ich werde Wireshark herunterladen und es auf den MSMQ-Server stellen und sehen, was es zeigt. Kann nicht auf die Webserver gestellt werden, es stürzt nach ca. 30 Sekunden aufgrund der Netzwerkverkehrslast ab.

— Mrdenny

Ich habe WireShark auf dem Computer gestartet und sehe zwischen den Nachrichten von dem einen Webserver, den ich überwache, ungefähr 3 Sekunden. Das sieht natürlich nicht gut aus.

— Mrdenny

Wir haben das anfängliche Problem gefunden, das ich oben in einem Kommentar angegeben habe. Danke für die Hilfe.

— Mrdenny

Wenn Sie auf Ihren Kommentar zum Mangel an Remoteverwaltung verweisen, ist dies mit MSMQ- und Perf-Zählern keine gute Geschichte. Wer dem Thread folgt und wissen möchte, welche Betriebssystemkombinationen funktionieren, sollte sich den Motley Queue-Blog ansehen:

MSMQ 4.0-Leistungsindikatoren und der Registrierungsschlüssel NetNameForPerfCounters http://blogs.msdn.com/motleyqueue/archive/2007/12/14/msmq-4-0-performance-counters-and-the-netnameforperfcounters-registry-key.aspx

Prost John Breakwell (MSFT)