(0) exportieren Drucken
Alle erweitern

Ressourcenverwaltung in MSMQ-Anwendungen

Veröffentlicht: 07. Mai 2003 | Aktualisiert: 22. Jun 2004
Von Chris Manderson und Travis Stanfield

In diesem Artikel erfahren Sie, wie Sie Ressourcen in Ihren MSMQ-Anwendungen (MSMQ, Microsoft Message Queuing) verwalten, indem Sie Speicher-, Datenträger- und Netzwerkengpässe vermeiden sowie MSMQ- und Systembeschränkungen berücksichtigen.

Auf dieser Seite

Einführung Einführung
Symptome und Fehler Symptome und Fehler
System- und MSMQ-Beschränkungen System- und MSMQ-Beschränkungen
Nachrichtengröße Nachrichtengröße
Nachrichtenspeicherkapazität Nachrichtenspeicherkapazität
Threading Threading
Auslagerungs- und Nichtauslagerungsspeicher Auslagerungs- und Nichtauslagerungsspeicher
Problembehandlung Problembehandlung
Nachrichtenkapazitäten Nachrichtenkapazitäten
Wiederherstellung Wiederherstellung
Vermeiden von Schwellenwerten der Nachrichtenkapazität Vermeiden von Schwellenwerten der Nachrichtenkapazität
Auslagerungs- und Nichtauslagerungsspeicher Auslagerungs- und Nichtauslagerungsspeicher
Zusammenfassung Zusammenfassung

Einführung

Die Art und Weise, wie eine Anwendung Ressourcen in ihrer Umgebung verwaltet, ist eine wichtige Überlegung bei der Entwicklung von Software. MSMQ-Anwendungen erfordern Ressourcen wie etwa Arbeitsspeicher (RAM), Datenträgerkapazität und in den meisten Fällen Netzwerkbandbreite. Wenn diese Ressourcen richtig genutzt und recycelt werden, führt dies dazu, dass Ihre Anwendungen und Dienste problemlos ausgeführt werden, eine hohe Verfügbarkeit besitzen und das System besser in der Lage ist, höhere Belastungen während Spitzenzeiten zu verkraften. In solchen Situationen zeigt sich dann, dass sich alle in den Entwurf gesteckten Mühen gelohnt haben.

Symptome und Fehler

Sobald die vom MSMQ-Dienst oder von MSMQ-Anwendungen genutzten Systemressourcen überschritten werden oder ihre Grenzen erreichen, können Warnzeichen auftreten oder die Nachrichtenverarbeitung kann sogar angehalten werden. Einige dieser Fehler oder Hinweise werden von Ihrer Anwendung empfangen, andere werden an die Ereignisanzeige gesendet und wieder andere erfordern eine weitere Untersuchung mithilfe von Diagnosetools.

Hier beispielhaft ein Fehler, der an Ihre Anwendung oder an die MSMQ-GUI-Tools wie MQExplorer oder Computerverwaltung zurückgegeben werden kann:

Es sind nicht genügend Ressourcen vorhanden, um den Vorgang auszuführen. Fehler 0xc00e0027

Anmerkung:
In Windows 2000 ist eine bekannte Ursache für einen C00E0027-Fehler, der nicht direkt mit der Ressourcenverwaltung im Zusammenhang steht, eine fehlende Übereinstimmung zwischen den MSMQ-DLLs und dem MSMQ Access Control Driver mqac.sys. Dies wird verursacht durch eine Deinstallation und erneute Installation von MSMQ nach Anwendung des Security Rollup Package 1 (SRP1). In diesem Fall wird der Access Control Driver nicht auf die vorherige Version des Service Packs zurückgesetzt.

Folgende Warnungen in Ihrer Anwendungsereignisanzeige können auf ein Ressourcenproblem hinweisen:

Ereigniskennung: 2070 
Dieser Computer hat wenig freien Arbeitsspeicher.  
Der Message Queuing-Dienst schaltet in den Modus für geringen Arbeitsspeicher um.

Auf diese Warnung kann folgendes Informationsereignis folgen:

Ereigniskennung: 2071 
Dieser Computer verfügt über ausreichend Arbeitsspeicher. 
Der Message Queuing-Dienst kehrt zu normalem Modus zurück.

Anmerkung:
Diese Ereignisprotokollmeldungen sind nur auf einem MSMQ 1.0-System sichtbar, das auf der NT 4.0-Plattform ausgeführt wird. In Windows 2000 werden diese Ereignisprotokollwarnungen nicht ausgelöst und benötigen für ihre Erkennung ein Diagnosetool. Weitere Informationen finden Sie im Artikel Q264936 (in Englisch) auf der Microsoft-Supportwebsite.

System- und MSMQ-Beschränkungen

Es gibt eine Reihe von Gründen, die in direktem Zusammenhang mit dem Funktionsumfang Ihres Systems oder dem von MSMQ stehen, die das Auftreten eines Ressourcenproblems verursachen können. Zu diesen gehören: Nachrichtengröße, Nachrichtenspeicherkapazität, Threading sowie Auslagerungs- und Nichtauslagerungsspeicher.

Nachrichtengröße

MSMQ unterstützt nur Nachrichten unter 4 MB, einschließlich Queued Components-Nachrichten. Alle Versuche, eine größere Nachricht über das System zu senden, führen zu einem Fehler vom Typ "Nicht genügend Ressourcen". Bedenken Sie, dass Unicode-Daten zwei Mal soviel Speicherplatz benötigen wie Nicht-Unicode-Daten, da für jedes Zeichen zwei Byte verwendet werden.

Nachrichtenspeicherkapazität

In MSMQ 1.0 und MSMQ 2.0 wird die Gesamtgröße von Nachrichten, die auf einem Computer gespeichert werden können, nicht durch die RAM-Größe des Computers oder die Größe der Festplatte eingeschränkt, sondern durch die Größe des virtuellen Adressraums, der dem MSMQ-Dienst vom Betriebssystem zur Verfügung gestellt wird. (Diese Einschränkung wurde in MSMQ 3.0 aufgehoben.) Jedem Prozess auf einem x86-Computer werden 4 GB mit adressierbarem Speicher zugewiesen. 2 GB sind für die Verwendung im Kernelmodus und 2 GB für den Benutzermodus reserviert. Der MSMQ-Warteschlangen-Manager arbeitet im Benutzermodus und kann deshalb einen adressierbaren virtuellen Adressraum von 2 GB nutzen. Die Daten jeder Nachricht werden im RAM gespeichert, der von der Auslagerungsdatei des Systems oder im Speicher abgebildeten Dateien unterstützt wird. MSMQ verwendet im Speicher abgebildete Dateien, um sowohl direkte als auch wiederherstellbare Nachrichten zu speichern. Da das Limit des adressierbaren Speichers 2 GB beträgt, sind auch die Nachrichten auf dem Datenträger auf 2 GB beschränkt. Wenn zudem der vom MSMQ-Code genutzte Arbeitsspeicher und seine internen Datenstrukturen berücksichtigt werden, sowie die Dateizuordnung zur Speicherung von Nachrichten auf dem Datenträger, verbleiben zwischen 1,4 GB und 1,6 GB für Nachrichten, die auf dem Datenträger gespeichert werden können.

Anmerkung:
Dieses Limit von 1,6 GB kann durch Aktivierung der 3-GB-Optimierung im MSMQ-Dienst auf etwa 2,6 GB erhöht werden. Weitere Informationen zur Aktivierung der 3-GB-Optimierung finden Sie im Artikel Q171793.

Threading

Asynchrone Rückrufe stellen ein verbreitetes Verfahren dar, um Anwendungen den Empfang von Benachrichtigungen über Ereignisse zu ermöglichen, die entweder lokal oder remote auftreten. Dieses Verfahren eignet sich gut für MSMQ-Anwendungsentwickler, da diese ein Ereignis zunächst abonnieren, sich anschließend anderen Arbeiten zuwenden, und später eine Benachrichtigung erhalten, dass ein Ereignis asynchron gemeldet wurde (Nachricht angekommen). Der Aufruf von MQReceiveMessage() mit Rückrufen bringt deutliche Einschränkungen und Konsequenzen mit sich. Die Einschränkung dieses Verfahrens besteht darin, dass nur 63 Rückrufe für einen Prozess durchgeführt werden können. Dies lässt sich auf die Art und Weise zurückführen, wie MSMQ für die Implementierung von Rückrufen entworfen wurde. Die Konsequenzen dieses Entwurfs lassen sich erkennen, wenn die Tatsache berücksichtigt wird, dass sich im Aufruf der WaitForMultipleObject-API durch einen Anwendungsprozess nur ein Thread verbirgt. Dieser einzelne Thread ist für die Aktivierung verantwortlich, wenn eines der 63 Ereignisse ausgelöst wird. Es wird von MSMQ intern jeweils nur ein Ereignis zu einem bestimmten Zeitpunkt verwendet, was weiterhin bedeutet, dass Rückrufe in einem Prozess serialisiert werden. Wenn eine Anwendung den 64. Aufruf von MQReceiveMessage() mit einem Rückruf durchführt und die anderen 63 Threads nach wie vor auf ihre Signalisierung warten, gibt der 64. Aufruf einen INSUFFICENT_RESOURCES-Fehler zurück.

Ein weiteres verbreitetes threadingbasiertes Szenario ist der Erhalt eines MQ_ERROR_INSUFFICIENT_RESOURCES-Fehlers bei Aufruf von MQReceiveMessage(), um aus einer Remotewarteschlange zu lesen. Wenn Anwendungen aus einer Remotewarteschlange lesen, wird ein Thread vom lokalen MSMQ-Dienst erstellt, der auf den Abschluss des Remotelesevorgangs auf dem Remotecomputer wartet. Der Standardschwellenwert für Threads, die zur Verarbeitung dieser Anforderungen erstellt werden, basiert hauptsächlich auf der verwendeten Betriebssystemversion. Die Höchstgrenze für Windows NT4 Workstation beträgt 16, für NT4 Server 64, für Windows 2000 Professional 24 und für Windows 2000 Server 96 Threads. Für die Windows XP Professional- und Windows 2003 Server-Betriebssystemfamilien gibt es keine Beschränkung. Sie können diese Höchstgrenzen ändern, indem Sie die DWORD-Registrierungswerte MaxRRThreads und MinRRThreads unter HKLM\software\microsoft\msmq\parameters hinzufügen und auf die gewünschten Dezimalwerte einstellen. Beachten Sie, dass der Registrierungseintrag MinRRThreads nicht in MSMQ 1.0-Systemen zur Verfügung steht. Weitere Informationen zu diesen Registrierungsschlüsseln finden Sie im Abschnitt zur Registrierung des Windows 2000 Resource Kit. Beachten Sie, dass in MSMQ 1.0 diese Threads bei Bedarf erstellt und nie bereinigt werden. Wenn Sie also diesen Wert auf 1000 einstellen und der Dienst tatsächlich 1000 Threads erstellt, sind alle diese Threads solange aktiv, wie der MSMQ-Dienst ausgeführt wird. Dieses Problem wurde in MSMQ 2.0 behoben.

Auslagerungs- und Nichtauslagerungsspeicher

Der Windows Memory Manager erstellt zwei Arten von dynamisch veränderbaren Speicherpools, die von der Kernelmodussoftware genutzt werden können, um Kernel-/Systemspeicher zuzuordnen. Theoretisch können diese Pools als Kernel-/Systemheaps betrachtet werden. Nichtauslagerungsspeicher ist dem physischen Arbeitsspeicher in etwa ähnlich, da sich dieser definitiv im Speicher befindet, bevor darauf zugegriffen wird. Zugriffe auf Nichtauslagerungsspeicher führen niemals zu Seitenfehlern.

Ein ausgelagerter Poolspeicher andererseits kann auf dem Datenträger ausgelagert werden. Da es sich hierbei um Systemspeicher handelt, werden diese Pools dem virtuellen Adressraum von 2 GB des Kernelmodus zugeordnet, der jedem Prozess zugewiesen ist. Es gibt Routinen wie etwa ExAllocatePool, die Zuordnungen aus diesen Pools vornehmen und rückgängig machen und im Microsoft Driver Development Kit (DDK) dokumentiert sind.

Die maximale Größe beider Pools wird vom Betriebssystem beim Systemstart ermittelt. Weitere Informationen finden Sie in den Artikeln Q126402 und Q312362 (beide in Englisch). Treiber, die Speicher zuweisen, können in ihren Anforderungen ein Tag mit vier Buchstaben angeben. Wenn die Poolnachverfolgung aktiviert ist, wird dieses Tag mit jeder Speicherzuweisung verknüpft und kann über Diagnosetools wie etwa poolmon.exe analysiert werden, um zu ermitteln, ob ein Verlust vorhanden ist (beachten Sie, dass die Tags für MSMQ-Speicher ab Windows 2000 MQAC, MQQM und MQXA lauten). Wie im Artikel Q264936 (in Englisch) beschrieben wird, hat eine Erschöpfung des Auslagerungspools ernsthafte Auswirkungen auf MSMQ. Aus diesem Grund ist ein Verständnis davon erforderlich, wie MSMQ den Kernelspeicher nutzt, da die Möglichkeit besteht, dass mit Millionen residenter Nachrichten das Limit von 1,4 bis 1,6 GB zwar nicht erreicht, der Auslagerungspool aber dennoch erschöpft wird. Jede Nachricht benötigt im Durchschnitt etwa 70 bis 80 Byte des Auslagerungspoolspeichers. Um zu ermitteln, ob Sie dieses Limit erreicht haben oder sich ihm nähern, sollten Sie den Systemmonitor ausführen und sich den Indikator Gesamtanzahl der Nachrichten in allen Warteschlangen des Objekts MSMQ-Dienst ansehen.

Problembehandlung

MSMQ-Ressourcenprobleme lassen sich entweder schnell beheben, wenn z.B. ein offensichtliches Detail im Anwendungsentwurf übersehen und ein MSMQ-Grenzwert erreicht wurde, oder es handelt sich um einen mühseligen Vorgang des Wartens und Beobachtens. Die Diagnose von Fakten, z.B. ob Sie Nachrichten über 4 MB senden oder den 1,6-GB-Grenzwert der MSMQ-Speicherkapazität erreichen, ist relativ einfach. Die Ermittlung, ob ein Threadingproblem vorliegt, kann schon etwas komplizierter sein, und die Entschlüsselung von Auslagerungspoolausgaben kann recht mühselig sein. Im Anschluss werden einige Tools und Verfahren beschrieben, die Supportmitarbeitern bei der Diagnose und Lösung dieser Probleme in der Vergangenheit geholfen haben.

Nachrichtenkapazitäten

Wenn Sie glauben, dass Sie die Größenbeschränkung für Nachrichten erreicht haben, sollten Sie die Nachricht in mehrere Teile aufteilen. Da MSMQ als einfaches Transportprotokoll für Daten entwickelt wurde, würden Nachrichten über 4 MB als unverhältnismäßig große Datenmengen für eine einzelne Transaktion angesehen werden.

Wenn Sie in das MSMQ-Speicherverzeichnis auf Ihrem Computer (in der Regel winnt\system32\msmq\storage) navigieren und der Dienst bei einer Gesamtgröße dieses Ordners zwischen 1,4 GB und 1,6 GB nicht startet, besteht eine große Wahrscheinlichkeit, dass Sie die maximale Speicherkapazität von MSMQ erreicht haben. In dieser Situation müssen zwei Schritte unternommen werden: Führen Sie eine Wiederherstellung durch, damit der MSMQ-Dienst diese Nachrichten verarbeiten kann. Treffen Sie anschließend Vorsorgemaßnahmen, damit diese Höchstgrenze kein zweites Mal überschritten wird. Das MSMQ-Produktentwicklungsteam arbeitet zusammen mit dem Microsoft-Produktsupport (PSS) an Tools, um die Wiederherstellung für Benutzer zu erleichtern, die das Limit für die MSMQ-Nachrichtenkapazität erreichen. Diese Tools ermöglichen es Benutzern, ausgewählte Nachrichten zu löschen, Nachrichtendateien zu defragmentieren sowie Nachrichten in Offlinedateien wiederzugeben.

Wiederherstellung

Zum jetzigen Zeitpunkt benötigen Sie für die Wiederherstellung die Unterstützung des Microsoft-Produktsupport (PSS), der mit Ihnen zusammenarbeitet, um diese Daten wiederherzustellen. Es gibt eine schnelle Methode zur Wiederherstellung der Betriebsbereitschaft Ihres Systems, indem Sie alle Dateien mit der Endung .mq innerhalb des Speicherverzeichnisses von MSMQ entfernen. Diese Dateien enthalten alle Ihre Nachrichten. Wenn Sie diese Dateien entfernen, während der Dienst außer Betrieb ist, und den Dienst dann neu starten, ist dieser zwar voll funktionsfähig, aber alle Ihre Warteschlangen sind leer. Dieser Ansatz wird nicht empfohlen, wenn Sie Transaktionsnachrichten senden, da diese der Reihe nach gesendet werden müssen. Sobald eine neuere Nachricht gesendet wurde, dürfen ältere Nachrichten nicht mehr gesendet werden. Entfernen Sie alle Nachrichtendateien nur dann, wenn es absolut notwendig ist, den Dienst so schnell wie möglich wieder zu starten.

Weitere Informationen zu den Dateien, die sich im MSMQ-Speicherverzeichnis befinden, finden Sie im Abschnitt über das Speichern von Nachrichten in der Message Queuing-Dokumentation, die in den Windows 2000 Server-Hilfedateien enthalten ist.

Vermeiden von Schwellenwerten der Nachrichtenkapazität

Die beste Methode zur Vermeidung dieser Situation ist die Implementierung von Kontingenten in Ihrer Message Queuing-Architektur. Dieser Vorgang besteht aus zwei Schritten.

Schritt 1. Festlegen eines Kontingents. Dieser Vorgang ist für alle Versionen von MSMQ ähnlich. In der Regel befinden sich diese Optionen in den Eigenschaften einer Warteschlange. Wenn Sie diese öffnen, können Sie die gewünschte Kontingentgröße für diese Warteschlange festlegen. Sobald das Kontingent für die Warteschlange oder den Computer erreicht ist, akzeptiert MSMQ in dieser Warteschlange oder auf diesem Computer keine Nachrichten mehr. Weitere Informationen zum Festlegen von Kontingenten finden Sie im Abschnitt über das Speichern von Nachrichten in der Message Queuing-Dokumentation, die in den Windows 2000 Server-Hilfedateien enthalten ist. Für MSMQ 2.0 können Sie im Arbeitsgruppenmodus das Kontingent durch Bearbeiten des Werts MachineQuota unter HKLM\Software\Microsoft\MSMQ\Parameters\MachineCache festlegen. Legen Sie für diesen Wert die KB-Größe aller kombinierten Nachrichten fest.

Schritt 2. Anforderung und Bestätigung. Kontingente verhindern zwar, dass Ihre Anwendungen den MSMQ-Dienst mit Nachrichten überfluten, steigern jedoch nicht die Flexibilität Ihrer Anwendung, sobald diese Kontingente erreicht werden. Für diesen Zweck können Sie eine Kontingentüberschreitungsbestätigung von dem Computer anfordern, an den Sie Nachrichten senden. Wenn diese Bestätigung nach Rückgabe an Ihre Anwendung besagt, dass das Kontingent für diese Warteschlange oder diesen Computer erreicht ist, kann Ihre Anwendung entweder mit dem Senden von Nachrichten aufhören oder die Nachrichten an ein anderes Ziel umschichten. Dies ist eine exzellente Methode für das dezentrale Skalieren von MSMQ. Weitere Informationen zu diesen Bestätigungen finden Sie unter Message Queuing (in Englisch) im Plattform-SDK unter dem Knoten "Message Queuing and Queue Components (MSMQ)" in der MSDN-Bibliothek.

Beachten Sie den Unterschied zwischen Computerkontingenten und Warteschlangenkontingenten. Sobald ein Computerkontingent erreicht ist, akzeptiert der Zielcomputer keine weiteren eingehenden Nachrichten. Diese Nachrichten sammeln sich dann in der ausgehenden Warteschlange des sendenden Computers oder auf Routingzwischenservern an. Um dieses Problem zu beheben, sollten Sie in einer Netzwerkmonitorausgabe des MSMQ-Datenverkehrs die MSMQ-Sitzungsherstellungspakete oder die MSMQ-Sitzungsbestätigungspakete untersuchen. Falls die Fenstergröße 1 beträgt, wurde das Computerkontingent erreicht.

Andererseits verwirft der Zielcomputer bei Erreichung eines Warteschlangenkontingents einfach die Nachricht. Aus diesem Grund ist es äußerst wichtig, bei Verwendung von Warteschlangenkontingenten auf dem Zielcomputer immer die korrekte Negativbestätigung (Negative Acknowledgement, Nack) für Kontingente anzufordern. Diese "Nack" wird vom Zielcomputer nur gesendet, wenn das Kontingent erreicht wurde.

Auslagerungs- und Nichtauslagerungsspeicher

Option 1. Ausführen des Programms "Talking Message Queue (TMQ) - State"
TMQ State ist derzeit nur über den Microsoft-Produktsupport (PSS) verfügbar. Führen Sie an der Eingabeaufforderung tmq state aus. Dadurch wird eine Protokolldatei mit der Bezeichnung tmqstate.log erstellt. In der Ausgabe dieser Protokolldatei werden Informationen zur Speicherverwendung angezeigt, die in etwa wie folgt aussehen:

Memory usage summary:  
   Physical Memory (K) 
   Total   3669532 
   Available  2237384 
   % 60 
   Pools limitations (calculated approximately, in KB) 
   Paged : limit 307200, used for 83 % 
   Nonpaged : limit 262144, used for 25 %

Beachten Sie, dass in diesem Beispiel das Betriebssystem ein Auslagerungspoollimit von ca. 307.200 KB berechnet hat. Da zudem über 80 % verbraucht sind, wurde der MSMQ-Niedrigspeichermodus aktiviert. Diese Informationen bestätigen, dass das Problem der unzureichenden Ressourcen sehr wahrscheinlich im Zusammenhang mit einem erschöpften Auslagerungspoolspeicher steht.

Option 2. Aktivieren von Pooltagging
Pooltagging kann durch Ausführen des Dienstprogramms Gflags.exe aktiviert werden. Sie erhalten dieses Dienstprogramm durch Downloaden der Debugger von der Site http://www.microsoft.com/ddk/debugging (in Englisch). Es ist auch in den Windows 2000-Supporttools, dem Plattform-SDK oder DDK verfügbar. Führen Sie Gflags.exe aus. Klicken Sie auf das Optionsfeld System Registry, und aktivieren Sie das Kontrollkästchen Enable pool tagging. Klicken Sie auf Apply, und starten Sie anschließend das System neu.

Führen Sie nach dem Neustart des Systems poolmon.exe -b aus. Dadurch werden die Pooldaten nach Zuordnungen geordnet. Da das System gerade neu gestartet wurde, sollte der Auslagerungspool leer und das Ressourcenproblem nicht mehr erkennbar sein. Rufen Sie im weiteren Verlauf regelmäßig poolmon.exe-Daten als Snapshots des Systemspeichers ab. Anhand dieser Snapshots lässt sich feststellen, ob ein oder mehrere Tags einen Speicherverlust aufweisen. Durch Ausführung von poolmon.exe -b können Sie feststellen, welche Tags den meisten Arbeitsspeicher verbrauchen. Wenn das Problem wiederholt auftritt, führen Sie poolmon.exe -b erneut aus. Wie im Artikel Q177415 gezeigt, kann anhand dieser Informationen ermittelt werden, ob tatsächlich ein Verlust vorliegt. Falls der Verlust nicht offensichtlich ist, lässt sich der Speicher-Manager so anpassen, dass ungenutzte Seiten vor Erreichung einer 80%igen Auslastung bereinigt werden. Weitere Informationen dazu finden Sie im Artikel Q312362 (in Englisch).

Option 3. Abrufen von Systemmonitordaten
Der Systemmonitor sollte während des gesamten Problemverlaufs für die Protokollierung von Daten eingerichtet werden. Dabei sollten alle Instanzdaten der Prozess- und Speicherobjekte (Process, Memory) sowie ihre Indikatoren abgerufen werden. Achten Sie besonders auf die Handleindikatoreninformationen der einzelnen Prozesse im Bezug auf Handleverluste. Unter dem Speicherobjekt (Memory) stehen die Indikatoren Auslagerungsseiten (Bytes) und Auslagerungsseiten reserviert zur Verfügung. Beachten Sie, dass diese Informationen zwar zum Erkennen eines auftretenden Verlusts hilfreich sein können, es jedoch keine Indikatoren für das Auslagerungspoollimit gibt. Informationen zur Ermittlung des Limits finden Sie unter Option 1. Bevor Sie die im Artikel Q312362 (in Englisch) beschriebenen Änderungen durchführen, müssen Sie wissen, welchen Prozentsatz des Auslagerungspools Ihr System im Durchschnitt verwendet. Eine Reduzierung des Werts für PoolUsageMaximum auf einen Prozentsatz unter dem Durchschnitt kann zu Leistungsproblemen führen.

Zusammenfassung

In diesem Artikel wurden die häufigsten Ursachen für das Auftreten von Ressourcenproblemen bei MSMQ erläutert und verschiedene Tools und Verfahren vorgestellt, die von Microsoft-Supportmitarbeitern verwendet werden, um bei der Problembehandlung und -vermeidung dieser Probleme behilflich zu sein. In Windows XP und Windows 2003 Server wurde die Erkennung von niedrigen Ressourcen wesentlich verbessert, um Benutzern eine Vielzahl von Möglichkeiten zur Diagnose ihrer Ressourcenprobleme zu bieten. Beim Umgang mit Systemressourcen können etwas Vorsorge und Planung einen großen Unterschied machen. Zudem lassen sich vor allem durch entsprechende Informationen diese Probleme schnell und effektiv beseitigen und vermeiden.


Anzeigen:
© 2014 Microsoft