(0) exportieren Drucken
Alle erweitern

Zu überprüfende Punkte während der der Problembehandlung für Message Queuing

Letzte Aktualisierung: Juni 2007

Betrifft: Windows Server 2008

Bei der Behandlung von Message Queuing-Problemen unter Microsoft Windows Vista® und Windows Server® 2008 sollten die folgenden Empfehlungen berücksichtigt werden.

Überprüfen Sie die Windows-Ereignisprotokolle im Hinblick auf Fehler und Warnungen.

Überprüfen Sie die Windows-Ereignisprotokolle der Message Queuing-Computer im Hinblick auf Fehler. Suchen Sie nach Fehler- oder Warnungsereignissen, für die unter Quelle der Text MSMQ angegeben wird, z. B. "MSMQ(MSMQ)" oder "MSMQ Cluster Resource". Sortieren Sie Ereignisse in der Ereignisanzeige nach ihrer Quelle, um Ereignisse mit dem Text "MSMQ" schnell identifizieren zu können. Suchen Sie dann unter http://support.microsoft.com nach der entsprechenden Ereignis-ID, nach dem Text in der Fehler- oder Warnungsbeschreibung oder nach Fehlercodes, die als Ereignisdaten in den Ereignisdetails zurückgegeben werden.

Weitere Informationen zur Verwendung der Ereignisanzeige finden Sie in der Windows-Onlinehilfe.

Verwenden Sie die Endpunktablaufverfolgung für die Behandlung von Problemen bei der Nachrichtenübermittlung.

Erwägen Sie die Aktivierung der Endpunktablaufverfolgung, um Probleme bei der Nachrichtenübermittlung zu behandeln.

Weitere Informationen finden Sie im Windows Vista- oder Windows Server 2008-Hilfethema "Problembehandlung mithilfe der Endpunktablaufverfolgung".

Überprüfen Sie die Computerkonnektivität.

Ungeachtet der Art des Konnektivitätsproblems oder der aufgetretenen Symptome empfiehlt sich die Verwendung des Dienstprogramms ping, um die Konnektivität eines Computers zu testen. Der Zeitraum, den ping für eine Antwort benötigt, kann auf ein Problem hinweisen. Auch wenn die Ausführung von ping nur zeitweise erfolgreich ist, kann dies einen Hinweis auf die Fehlerursache liefern. Ein unregelmäßiger Erfolg deutet auf Probleme wie eine Netzwerküberlastung oder einen Fehler bei der Namensauflösung hin, sodass die Namensauflösung per Broadcast erfolgen muss.

Überprüfen Sie, ob mit ping der vollständige DNS-Name des fraglichen Computers aufgelöst werden kann. Ist dies nicht der Fall, müssen Sie den DNS-Server überprüfen.

noteHinweis
Durch die Windows-Firewall werden ICMP-Echonachrichten (ping) standardmäßig deaktiviert. Wenn Sie ping zum Überprüfen der Namensauflösung verwenden, kann es zuvor notwendig sein, ICMP-Anforderungen und -Antworten vorübergehend in der Windows-Firewall zuzulassen.

Wenn die Messagingfunktion firewallübergreifend verwendet wird, ist die Verwendung von ping, das auf Internet Control Message Protocol (ICMP) basiert, aus zwei Gründen nicht empfehlenswert:

  • Es ist nicht sitzungsbasiert. Die Fähigkeit zum Aufbau einer TCP-Sitzung wird daher nicht überprüft.

  • ICMP wird von Firewalls nur selten zugelassen, da es in erster Linie zur Kontrolle von Netzwerkgeräten verwendet wird..

  • Im Domänenmodus sollten Sie das MSMQ-Diagnosetool MQPing verwenden. Weitere Informationen zur Verwendung des Diagnosetools MQPing finden Sie unter Testen der Konnektivität mittels MQPing.

Weitere Konnektivitätsprobleme können durch eine Netzwerkmonitor-Ablaufverfolgung (NetMon) isoliert werden. Mithilfe einer solchen Ablaufverfolgung können Sie den Gegenstand eines Versuchs von Message Queuing, eine Sitzung aufzubauen, ermitteln, und Sie können feststellen, in welchem Teil des Verbindungsvorgangs der Fehler auftritt. Mit NetMon können Sie zudem Situationen identifizieren, in denen zwar die Verbindung zwischen zwei Computern erfolgreich hergestellt werden konnte, aber die Überprüfung durch einen Domänencontroller nicht erfolgreich war.

Weitere Informationen zur Verwendung des Netzwerkmonitors zum Überwachen und Erfassen des Netzwerkverkehrs finden Sie in der Windows-Onlinehilfe.

Untersuchen Sie die Ressourcenverwendung.

Bei niedriger Verarbeitungsgeschwindigkeit und hohem Ressourcenverbrauch sind die MSMQ-Leistungsindikatoren im Systemmonitor äußerst hilfreich. Sie können auf die Indikatoren zugreifen, indem Sie auf Start und danach auf Ausführen klicken und anschließend perfmon eingeben. Die Indikatoren können die folgenden Probleme anzeigen:

  • Nachrichten, die sich in Journalwarteschlangen oder Bestätigungswarteschlangen ansammeln. Möglicherweise haben Sie vergessen, dass die Journalfunktion aktiviert ist.

  • Ausstehende ausgehende Nachrichten. Dies ist sehr hilfreich, da ausstehende Nachrichten von keinem anderen Verfahren erkannt werden.

  • Speicherauslastung oder -verbrauch. Dies kann ein gängiges Problem beim Senden von COM-Objekten sein.

Ausgehende Nachrichten können folgendermaßen untersucht werden:

  • Durch Leistungsindikatoren (siehe vorherige Beschreibung).

  • Durch das Message Queuing-MMC-Snap-In in Computerverwaltung.

  • Lokale Verwaltungs-APIs, die u. a. Folgendes ermöglichen:

    • Auflisten lokaler privater Warteschlangen

    • Auflisten interner ausgehender Warteschlange

    • Auflisten des Status der ausgehenden Warteschlange (verbunden, nächster Hop, Nachrichtenanzahl)

    • Anhalten/Fortsetzen der ausgehenden Warteschlange

    • Offlineschalten/Onlineschalten des gesamten Warteschlangen-Managers

    • Lesen/Löschen von Nachrichten in der ausgehenden Warteschlange

Beachten Sie die Grenzwerte für die Nachrichtengröße.

Nachrichten werden in MQ-Dateien gespeichert. Eine MQ-Datei stellt keine bestimmte Warteschlange dar. Nachrichten aus mehreren Warteschlangen können in einer MQ-Datei gespeichert werden, und Nachrichten aus einer einzigen Warteschlange können in mehreren MQ-Dateien gespeichert werden. Eine einzelne Nachricht kann sich jedoch nicht über mehrere MQ-Dateien erstrecken. Aus diesem Grund kann eine Nachricht nicht mehr als 4 MB umfassen.

Jeder Versuch, eine Nachricht über das System zu senden, die diesen Wert überschreitet, löst einen Fehler aufgrund unzureichender Ressourcen aus. Bedenken Sie, dass Unicode-Daten doppelt so viel Speicherplatz beanspruchen wie Nicht-Unicode-Daten, da für jedes Zeichen zwei Bytes benötigt werden.

Beachten Sie Threadingbeschränkungen.

Programmierer setzen häufig eine bestimmte Technik, so genannte asynchrone Rückrufe ein, damit eine Anwendung über lokal oder remote auftretende Ereignisse benachrichtigt wird. Diese Technik eignet sich gut für die Entwicklung von Message Queuing-Anwendungen, da sie ein Ereignis abonnieren können, die Arbeit dann fortsetzen und asynchron benachrichtigt werden, wenn ein Ereignis eingetreten (eine Nachricht eingetroffen) ist.

Für den Aufruf von MQReceiveMessage() mit Rückrufen gilt jedoch eine Einschränkung: Für jeden beliebigen Prozess sind maximal 63 Rückrufe zulässig. Diese Beschränkung hängt mit der Art der Implementierung von Rückrufen in Message Queuing zusammen. Die damit verbundenen Folgen werden klarer, wenn Sie sich vor Augen führen, dass es in einem Anwendungsprozess faktisch nur einen Thread gibt, der die WaitForMultipleObject-API aufruft. Dieser Thread muss aktiviert werden, wenn eines der 63 Ereignisse ausgelöst wird. Intern wird von Message Queuing immer nur jeweils ein Ereignis verwendet. Das bedeutet auch, dass Rückrufe in einem Prozess serialisiert werden. Wenn eine Anwendung MQReceiveMessage() zum 64. Mal mit einem Rückruf aufruft und die übrigen 63 Threads noch auf die Signalisierung warten, wird für den 64. Aufruf der Fehler INSUFFICENT_RESOURCES zurückgegeben.

Ein weiteres gängiges threadingbasiertes Szenario ist, dass der Fehler MQ_ERROR_INSUFFICIENT_RESOURCES zurückgegeben wird, wenn MQReceiveMessage() aufgerufen wird, um eine Remotewarteschlange zu lesen. Wenn eine Anwendung eine Remotewarteschlange liest, wird ein Thread durch den lokalen Message Queuing-Dienst erstellt. Dieser Thread wartet auf die Beendigung des Remotelesevorgangs auf dem Remotecomputer. Der Standardschwellenwert für Threads, die zur Verarbeitung dieser Anforderungen erstellt werden, hängt vor allem von der Version des verwendeten Betriebssystems ab. Der Grenzwert für Windows 2000 Server ist 96. Für Windows XP Professional, Windows Server 2003, Windows Vista und Windows Server 2008 gibt es keinen Grenzwert.

Sie können diese Grenzwerte ändern, indem Sie die DWORD-Registrierungseinträge MaxRRThreads und MinRRThreads unter dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\MSMQ\Parameters erstellen und die entsprechenden Maximal- und Mindestwerte festlegen. Führen Sie nach dem Festlegen des Registrierungswerts einen Neustart des Message Queuing-Diensts aus, damit die Änderungen in Kraft treten.

CautionVorsicht
Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Schäden am System verursacht werden. Es empfiehlt sich, alle auf dem Computer befindlichen wichtigen Daten zu sichern, bevor Sie Änderungen an der Registrierung vornehmen.

Vermeiden Sie Nachrichtenkapazitätsschwellenwerte.

Die beste Strategie, um eine derartige Situation zu vermeiden, ist die Implementierung von Kontingenten bei der Bereitstellung von Message Queuing. Dieser Prozess umfasst zwei Schritte:

  1. Festlegen von Computer- oder Warteschlangenkontingenten. Beachten Sie den Unterschied zwischen Computerkontingenten und Warteschlangenkontingenten. Wenn ein Computerkontingent erreicht ist, werden vom Zielcomputer keine weiteren eingehenden Nachrichten akzeptiert, und die Nachrichten sammeln sich in der ausgehenden Warteschlange des sendenden Computers oder auf einem zwischengeschalteten Routingserver an. Sie können dieses Problem beseitigen, indem Sie sich eine Netzwerkmonitoraufnahme des Message Queuing-Verkehrs verschaffen und sich die Pakete zum Aufbau der MSMQ-Sitzung oder die Pakete zur Bestätigung der MSMQ-Sitzung anschauen. Wenn die Fenstergröße 1 beträgt, wurde das Computerkontingent erreicht. Wenn ein Warteschlangenkontingent erreicht wurde, wird die Nachricht vom Zielcomputer abgelehnt. Daher ist es unverzichtbar, immer die richtige negative Bestätigung für Kontingente anzufordern, wenn Warteschlangenkontingente auf dem Zielcomputer verwendet werden. Diese negative Bestätigung wird nur dann vom Zielcomputer gesendet, wenn das Kontingent erreicht wurde. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 899612 zum Einrichten von Computerkontingenten und Warteschlangenkontingenten in Message Queuing unter http://support.microsoft.com/kb/899612 (möglicherweise in englischer Sprache).

  2. Anforderung und Bestätigung. Mithilfe von Kontingenten wird verhindert, dass Anwendungen den Message Queuing-Dienst überschwemmen. Sie tragen jedoch nicht dazu bei, dass die Anwendungen flexibler reagieren, wenn diese Kontingente erreicht wurden. Zu diesem Zweck können Sie eine NACK-Nachricht (negative Bestätigung) von dem Computer anfordern, an den Nachrichten gesendet werden. Wenn diese Bestätigung an eine Anwendung zurückgegeben wird und darauf hinweist, dass das Kontingent für diese Warteschlange oder diesen Computer erreicht wurde, kann die Anwendung entweder das Senden von Nachrichten einstellen oder die Nachrichten zu einem anderen Ziel verlagern. Dieses Verfahren eignet sich sehr gut für die horizontale Skalierung von Message Queuing. Weitere Informationen zu diesen Bestätigungen finden Sie in der Message Queuing-Dokumentation zu Bestätigungsmeldungen in MSDN (möglicherweise in englischer Sprache).

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft