Behandeln von Problemen bei einem Speicherverlust oder einer Ausnahme vom Typ "Nicht genügend Arbeitsspeicher" im BizTalk Server-Prozess

  • Artikel

In diesem Artikel wird beschrieben, wie Sie einen Speicherverlust oder eine Nicht genügend Arbeitsspeicherausnahme im BizTalk Server Prozess von Microsoft BizTalk Server beheben.

Ursprüngliche Produktversion: BizTalk Server 2010, 2009
Ursprüngliche KB-Nummer: 918643

Zusammenfassung

Speicherverluste sind ein häufiges Problem. Möglicherweise müssen Sie mehrere Schritte ausführen, um die spezifische Ursache für einen Speicherverlust oder eine OOM-Ausnahme (Nicht genügend Arbeitsspeicher) in Microsoft BizTalk Server zu finden. In diesem Artikel werden wichtige Aspekte erläutert, die Bei der Auswertung der Speicherauslastung und mögliche Speicherprobleme zu berücksichtigen sind. Zu diesen Überlegungen gehören die folgenden Aspekte:

  • Physischer RAM
  • Verarbeitung großer Nachrichten
  • Verwenden des Schalters "/3 GB"
  • Verwenden von benutzerdefinierten Komponenten
  • Welche Version von Microsoft .NET Framework das System ausgeführt wird
  • Die Anzahl der Prozessoren

Bei der BizTalk Server Kann es zu einem Speicherverlust kommen, wenn die Arbeitsspeicherauslastung im Microsoft Windows-Task-Manager mehr als 50 Prozent des physischen RAM verbraucht. Ein Arbeitsspeicherverlust kann zu einer Ausnahme vom Typ "Nicht genügend Arbeitsspeicher" führen, wenn die Arbeitsspeicherauslastung zunimmt, bis der Systemarbeitsspeicher für den Prozess nicht mehr ausreicht oder der Prozess nicht mehr funktioniert. Berücksichtigen Sie für dieses Problem Folgendes:

Physische Ram- und Arbeitsspeicherauslastung

Da es möglicherweise zu erwarten ist, dass ein Prozess etwa die Hälfte des physischen RAM verwendet, verwenden Sie die Speicherauslastung als Richtlinie. Wenn der BizTalk Server beispielsweise 4 Gigabyte (GB) RAM aufweist und der BizTalk Server Prozess etwa 500 Megabyte (MB) RAM verwendet, kann es zu keinem Verlust kommen. Wenn der BizTalk Server Prozess etwa 1 GB RAM verwendet, kann es zu einem Speicherverlust oder zu einer hohen Arbeitsspeichersituation kommen. Der Arbeitsspeicherverbrauch kann durch eine gespeicherte Prozedur oder Orchestrierung mit langer Ausführungsdauer verursacht werden. Stellen Sie sicher, dass Sie wissen, wie viel Arbeitsspeicher der BizTalk-Host in der Regel verwendet, um zu bestimmen, ob ein Speicherverlust oder eine hohe Arbeitsspeicherauslastung vorliegt.

Große Nachrichten

Wenn BizTalk Server große Nachrichten verarbeitet, scheint das System einen Speicherverlust zu haben. Die Nachrichten verwenden jedoch möglicherweise eine große Menge an Arbeitsspeicher.

Beachten Sie außerdem, dass eine hohe Arbeitsspeicherauslastung zu erwarten ist, wenn BizTalk Server große Nachrichten verarbeitet. Möglicherweise möchten Sie Ihre Hardware aktualisieren, um die Leistungsanforderungen von BizTalk Server in Ihrer Umgebung zu erfüllen.

Wie lange es dauert, den Speicherverlust zu reproduzieren

Speicherverluste können sofort auftreten oder sich im Laufe der Zeit ansammeln. Beide Szenarien sind üblich.

Verwenden des /3GB-Schalters auf 32-Bit-Computern

In der Regel kann ein Prozess auf 2 GB virtuellen Adressraum zugreifen. Der Schalter /3GB ist eine Option für Systeme, die mehr adressierbaren Arbeitsspeicher benötigen. Diese Option kann die Speicherauslastung für die Verarbeitung von Nachrichten verbessern. Der Schalter "/3 GB " lässt jedoch nur 1 GB adressierbaren Arbeitsspeicher für Kernelmodusvorgänge zu. Darüber hinaus kann dieser Schalter das Risiko erhöhen, dass der Poolarbeitsspeicher ausgeht.

Wenn der Schalter /3GB unter einer 32-Bit-Version von Windows aktiviert ist, kann der Prozess auf 3 GB virtuellen Adressraum zugreifen, wenn der Prozess große Adressen unterstützt. Ein Prozess ist mit großen Adressen kompatibel, wenn für die ausführbare Datei das flag IMAGE_FILE_LARGE_ADDRESS_AWARE im Imageheader festgelegt ist. Da der BizTalk-Prozess große Adressen unterstützt, profitiert BizTalk von der Option /3GB.

Wenn ein 32-Bit-BizTalk-Host instance unter einer 64-Bit-Version von Windows (AMD64) ausgeführt wird, profitiert der BizTalk-Prozess vom 4-GB-Speicheradressraum, da BizTalk große Adressen unterstützt. Daher ist das Verschieben Ihrer Anwendungen mit hohem Arbeitsspeicher auf einen 64-Bit-Server möglicherweise die beste Lösung.

Ein 64-Bit-BizTalk-Prozess unter einer 64-Bit-Version von Windows (AMD64) verfügt über 8 TB adressierbaren Arbeitsspeicher.

Sie sollten auch die virtuellen Bytes und die privaten Bytes berücksichtigen, die vom Prozess verwendet werden. Ein BizTalk-Host instance (bei dem es sich um eine .NET Framework-Anwendung handelt) erhält möglicherweise einen Fehler vom Typ "Nicht genügend Arbeitsspeicher", bevor der Wert "Virtuelle Bytes" 2 GB erreicht. Diese Situation kann auftreten, obwohl der maximale Arbeitsspeicher, der von einem Prozess unter einer 32-Bit-Version von Windows (ohne den Schalter /3GB) adressierbar ist, 2 GB beträgt. Eine Erläuterung, warum diese Situation auftreten kann, finden Sie auf der folgenden Website des Microsoft Developer Network (MSDN):
ASP.NET leistungsüberwachung und wann Warnungsadministratoren zu beachten sind

Der Schalter /3GB erhöht auch die maximale Anzahl privater Bytes des BizTalk-Prozesses von 800 MB auf 1800 MB. Weitere Informationen zur .NET Framework Anwendungsleistung mit aktiviertem /3GB-Schalter finden Sie unter Kapitel 17 – Optimieren der Leistung von .NET-Anwendungen.

Die folgende Tabelle fasst diese Informationen zusammen und enthält die praktischen Grenzwerte für virtuelle und private Bytes.

Prozess Windows Adressierbarer Speicher (mit einem großen adressfähigen Prozess) Praktischer Grenzwert für virtuelle Bytes Praktischer Grenzwert für private Bytes
32-Bit 32-Bit 2 GB 1400 MB 800 MB
32-Bit 32-Bit mit /3 GB 3 GB 2400 MB 1800 MB
32-Bit 64-Bit 4 GB 3400 MB 2800 MB
64-Bit 64-Bit 8 TB Nicht zutreffend Nicht zutreffend

Weitere Informationen zum adressierbaren Arbeitsspeicher für 32-Bit- und 64-Bit-Windows finden Sie unter Arbeitsspeichergrenzwerte für Windows- und Windows Server-Versionen.

In der folgenden Tabelle sind PAE und 3 GB Unterstützungsmöglichkeiten für verschiedene Versionen von BizTalk Server aufgeführt.

Produkt PAE 3 GB
BizTalk Server 2004 Ja Nein
BizTalk Server 2006 Ja Ja
BizTalk Server 2006 R2 Ja Ja
BizTalk Server 2009 Ja Ja

Wenn Sie den Schalter /3GB aktivieren müssen, um die Leistungsanforderungen eines Computers zu erfüllen, auf dem BizTalk Server ausgeführt wird, sollten Sie erwägen, server zur BizTalk-Gruppe hinzuzufügen. Dadurch können Sie die speicherintensiven Hostinstanzen horizontal hochskalieren.

BizTalk-Komponenten, die in einem IIS-Prozess (Internet Information Services) ausgeführt werden, können auch von Vorteil sein, wenn der Schalter /3GB aktiviert ist.

Der Schalter /3GB wird auf Computern mit Windows SharePoint Services 2.0 oder höheren Versionen oder SharePoint Portal Server 2003 SP2 oder höheren Versionen nicht unterstützt. Der Windows Server 2003/3GB-Switch wird in Windows SharePoint Services 2.0 oder höheren Versionen oder in SharePoint Portal Server 2003 Service Pack 2 oder höheren Versionen nicht unterstützt.

Verwenden von benutzerdefinierten Komponenten

Wenn Sie benutzerdefinierte Komponenten wie Pipelines oder Dienstkomponenten verwenden, müssen Sie wissen, was diese Komponenten tun. Sie sollten auch die potenziellen Auswirkungen dieser Komponenten auf die Speicherauslastung kennen. Ein häufiges Speicherproblem tritt auf, wenn eine Komponente ein Dokument transformiert. Der Transformationsvorgang ist ein speicherintensiver Vorgang. Wenn ein Dokument transformiert wird, übergibt BizTalk Server den Nachrichtenstream innerhalb des BizTalk-Prozesses an die Microsoft .NET Framework-KlasseXslTransform.

Ein weiteres häufiges Problem tritt auf, wenn eine intensive Zeichenfolgenbearbeitung erfolgt. Intensive Zeichenfolgenbearbeitung kann viele Erinnerungen verbrauchen. Weitere Informationen zu Möglichkeiten zum Verbessern der Leistung finden Sie unter Verbessern der Leistung von verwaltetem Code.

Version des .NET Framework

Microsoft .NET Framework 2.0 und .NET Framework 1.1 weisen ein anderes Speicherverhalten auf. Es können also unterschiedliche Ergebnisse zwischen ihnen angezeigt werden. Wenn Sie das .NET Framework verwenden, vergewissern Sie sich, dass das neueste .NET Framework Service Pack 1 installiert ist. Mit diesen Service Packs werden mehrere bekannte Speicherprobleme behoben.

Anzahl der Prozessoren

Die Common Language Runtime (CLR) verfügt über die folgenden Garbage Collectors (GCs):

  • Arbeitsstation (Mscorwks.dll)
  • Server (Mscorsvr.dll)

Wenn der Computer, auf dem BizTalk Server ausgeführt wird, ein Mehrprozessorsystem ist, verwendet der .NET Framework die Serverversion der Ausführungs-Engine. Dies ist das Standardverhalten. Der Garbage Collector des Servers ist auf maximalen Durchsatz ausgelegt. Darüber hinaus wird der Garbage Collector des Servers skaliert, um eine hohe Leistung zu erzielen. Dieser Garbage Collector belegt Arbeitsspeicher und gibt später Arbeitsspeicher frei, um eine hohe Leistung auf dem System zu erzielen. Daher scheint ein Computer, auf dem BizTalk Server zusammen mit einigen .NET Framework Komponenten ausgeführt wird, einen Speicherverlust zu haben. In diesem Szenario ist jedoch eine hohe Speicherauslastung das erwartete Verhalten. Wenn der Systemarbeitsspeicher auf dem Computer ausgeht oder der Prozess aufgrund unzureichenden adressierbaren Arbeitsspeichers nicht mehr funktioniert, kann ein Speicherverlust auftreten.

Wenn der Computer, auf dem BizTalk Server ausgeführt wird, ein Einzelnes Prozessorsystem ist, verwendet der .NET Framework die Arbeitsstationsversion der Ausführungs-Engine. Dies ist das Standardverhalten. Der Garbage Collector-Zuordnungsalgorithmus der Arbeitsstation ist nicht für die Skalierung oder den maximalen Durchsatz konzipiert. Dieser Garbage Collector verwendet gleichzeitige Garbage Collector-Methoden. Diese Methoden sind für Anwendungen mit komplexen Benutzeroberflächen konzipiert. Solche Anwendungen erfordern möglicherweise eine aggressivere Garbage Collection.

Wichtig

Dieser Abschnitt, diese Methode bzw. diese Aufgabe enthält eine Beschreibung der Schritte zum Bearbeiten der Registrierung. Wenn Sie die Registrierung falsch ändern, können jedoch schwerwiegende Probleme auftreten. Stellen Sie daher sicher, dass Sie diese Schritte sorgfältig ausführen. Für zusätzlichen Schutz sichern Sie die Registrierung, bevor Sie sie ändern. Sie können die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter Sichern und Wiederherstellen der Registrierung in Windows.

Manchmal kann es sinnvoll sein, die Arbeitsstationsversion der Ausführungs-Engine auf einem Multiprozessorsystem auszuführen. Sie können den folgenden Registrierungsschlüssel verwenden, um zur Arbeitsstationsversion der Ausführungs-Engine zu wechseln.

BizTalk 2006 und höhere Versionen

Create:CRL Hosting Zeichenfolgenregistrierungsschlüssel mit den entsprechenden Werten:

  • Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • Wertname: Flavor
  • Wertdaten: wks

BizTalk 2004

Create:CRL Host Zeichenfolgenregistrierungsschlüssel mit den entsprechenden Werten:

  • Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • Wertname: Flavor
  • Wertdaten: wks

Weitere Informationen finden Sie unter Leistungsüberlegungen für Run-Time Technologien im .NET Framework.

Im Folgenden finden Sie häufige Ursachen und Lösungen:

Schwellenwerte für die Drosselung von Prozessen und physischem Arbeitsspeicher

Die Schwellenwerte für die Verarbeitungsspeicherauslastung und die Physische Speicherauslastung können in BizTalk Server 2006 und höheren Versionen geändert werden.

  • Standardmäßig ist der Schwellenwert für die Prozessarbeitsspeicherauslastung auf 25 festgelegt. Wenn dieser Wert überschritten wird und die Speicherauslastung des BizTalk-Prozesses mehr als 300 MB beträgt, kann eine Drosselungsbedingung auftreten. Auf einem 32-Bit-Server können Sie den Wert der Prozessspeicherauslastung auf 50 erhöhen. Auf einem 64-Bit-Server können Sie diesen Wert auf 100 erhöhen. Dies ermöglicht eine größere Arbeitsspeicherauslastung durch den BizTalk-Prozess, bevor eine Drosselung auftritt.

  • Der Schwellenwert für die Drosselung des physischen Speichers weist den Standardwert 0 auf. Dieser Schwellenwert misst den gesamten Systemspeicher. Wenn daher ein anderer Wert als 0 konfiguriert ist, kann eine Einschränkungsbedingung auftreten, wenn ein Nicht-BizTalk-Prozess viel Arbeitsspeicher verwendet.

Schwellenwerte für die Dehydrierungsdrosselung

Die Standardmäßigen Schwellenwerte für die Speicherauslastung können zu einer zu großen Dehydrierung führen, wenn Orchestrierungen auf einem 64-Bit-Host ausgeführt werden. Weitere Informationen zu diesem Problem finden Sie unter Standardeigenschaften für Austrocknung.

Hinweis

64-Bit-Hosts werden in BizTalk Server 2006 und höheren Versionen unterstützt.

Auf gleichwertiger Hardware in einem 32-Bit-Host instance ist die beobachtete Austrocknung nominal, wenn dieselben Orchestrierungen unter Verwendung der standardmäßigen Schwellenwerte für speicherdehydrierte Drosselung ausgeführt werden.

Da die 64-Bit-Architektur einen erweiterten Speicheradressraum (16 TB anstelle von 4 GB) bereitstellt, wird 64-Bit-Hostinstanzen mehr Arbeitsspeicher zugewiesen als 32-Bit-Hostinstanzen. Dies kann dazu führen, dass die Standardschwellenwerte für die Speicherdrosselung überschritten werden.

Um dieses Verhalten zu umgehen, ändern Sie die Werte VirtualMemoryThrottlingCriteria und PrivateMemoryThrottlingCriteria in der BTSNTSvc64.exe.config-Datei. Verwenden Sie die Leistungsindikatoren \Process\Virtual Bytes und \Process\Private Bytes Leistungsmonitor, um die größte Arbeitsspeichermenge zu ermitteln, die von einem Orchestrierungs-instance zugewiesen wird.

  • Legen Sie den OptimalUsage-Wert für beide Eigenschaften basierend auf folgendem Fest:

    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes-Wert + 10 %

  • Legen Sie MaximalUsage für beide Eigenschaften auf den OptimalUsage-Wert + 30 % fest.

Beispiel: Wenn \Process\Virtual Byte Leistungsmonitor Zählerwert für eine Orchestrierungs-instance 5.784.787.695 Bytes (5.517 MB) ist, legen Sie den OptimalUsage-Wert für VirtualMemoryTh fest.RottlingCriteria auf 6.069 MB (5.784.787.695 * 1,10 = 6.363.266.464,5 Byte).

Legen Sie den MaximalUsage-Wert für VirtualMemoryThrottlingCriteria auf 7.889 MB (6.363.266.464.5 * 1,30 = 8.272.246.403,85 Byte) fest.

Wenn der Zählerwert \Process\Private Bytes Leistungsmonitor 435689400 Bytes (415 MB) beträgt, legen Sie den OptimalUsage-Wert für PrivateMemoryThrottlingCriteria auf 457 MB fest (435689400 * 1,10 = 479258340 Bytes).

Legen Sie den MaximalUsage-Wert für PrivateMemoryThrottlingCriteria auf 594 MB fest (479258340 * 1,30 = 623035842).

In diesem Beispiel würden die folgenden Werte in der BTSNTSvc64.exe.config-Datei angegeben, um die Drosselung zu reduzieren.

Leistungsmonitor Zähler Zugewiesener Arbeitsspeicher OptimalUsage MaximalNutzung
\Process\Virtual Bytes 5.784.787.695 Bytes (5517 MB) 6069 7889
\Process\Private Bytes 435.689.400 Bytes (415 MB) 457 594

Diese Werte werden dann in der BTSNTSvc64.exe.config-Datei wie folgt dargestellt:

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

Um zu bestimmen, welcher Host instance die Orchestrierung ausführt, können Sie den ID-Prozess aus den Leistungsindikatoren \BizTalk: Messaging\ID Process und \Process\ID Process Leistungsmonitor abgleichen. Überprüfen Sie dann den Durchschnittswert, der für die entsprechenden Indikatoren \Process\Virtual Bytes und \Process\Private Bytes Leistungsmonitor angezeigt wird.

Hinweis

Informationen, die der Benutzer auch bei Skimming bemerken sollteDie hohe Austrocknung kann zu einer erheblichen Leistungseinbuße führen, wenn die BizTalkMsgBoxDb Datenbank am SQL Server 2008 ausgeführt wird.

BizTalk Server Service Packs und kumulativen Updates

BizTalk Server Service Packs und kumulativen Updates enthalten die neuesten Fixes. Dazu gehören solche, die bekannte System.OutOfMemoryException Probleme betreffen.

Heapdecommitfreeblockthreshold

Standardmäßig ist der HeapDeCommitFreeBlockThreshold Registrierungsschlüsselwert 0. Der Wert 0 bedeutet, dass der Heap-Manager die Commits für jede 4-KB-Seite dekompromittiert, die verfügbar wird. De-Commit-Vorgänge können zu einer Fragmentierung des virtuellen Speichers führen. Die Größe der HeapDeCommitFreeBlockThreshold Einstellung im Heap-Manager hängt von der Art der Arbeit ab, die das System ausführt. Eine Größe von 0x00040000 ist ein empfohlener Startwert.

Berücksichtigen Sie die folgenden Informationen, bevor Sie den Wert des HeapDeCommitFreeBlockThreshold Registrierungsschlüssels ändern:

  • Diese Änderung gilt nur für Speicherfragmentierungsprobleme.
  • Diese Änderung erfolgt systemweit. Daher verbrauchen die meisten Prozesse beim Start mehr Arbeitsspeicher.
  • Betrachten Sie diese Änderung nur für Systeme, die BizTalk Server als primäre Aufgabe haben.

Um die Fragmentierung des virtuellen Speichers zu verringern, können Sie die Größe der HeapDeCommitFreeBlockThreshold Einstellung im Heap-Manager erhöhen, indem Sie den Wert des folgenden Registrierungsschlüssels unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Managerändern:

  • Wertname: HeapDeCommitFreeBlockThreshold
  • Werttyp: REG_DWORD
  • Wertdaten: 0x00040000 (Dies ist der empfohlene Anfangswert.)
  • Standardwert: nicht vorhanden

Transformationsvorgänge

Wenn BizTalk Server XML-Transformationsvorgänge für relativ große Nachrichten in einem Empfangsport, in einem Sendeport oder in XLANGausführt, laden XSL-Transformationen die gesamte Nachricht im Arbeitsspeicher.

Wenden Sie eine der folgenden Methoden an, um dieses Problem zu beheben:

  • Reduzieren Sie die Anzahl der Nachrichten, die BizTalk Server gleichzeitig verarbeitet.
  • Verringern Sie die Größe der XML-Nachricht, die transformiert wird.

Das System.Policy.Security.Evidence -Objekt wird häufig in Transformationen verwendet und kann viel Arbeitsspeicher verbrauchen. Wenn eine Zuordnung eine Skripterstellung functoid enthält, die Inline-C# (oder eine andere Inlinesprache) verwendet, wird die Assembly im Arbeitsspeicher erstellt. Das System.Policy.Security.Evidence -Objekt verwendet das -Objekt der tatsächlich aufrufenden Assembly. In dieser Situation wird ein Rootobjekt erstellt, das erst gelöscht wird, wenn der BizTalk-Dienst neu gestartet wird.

Die meisten Standardmäßigen BizTalk functoids werden als Inlineskript implementiert. Diese Elemente können dazu führen, dass System.Byte[] Objekte im Arbeitsspeicher gesammelt werden. Um den Arbeitsspeicherverbrauch zu minimieren, empfiehlt es sich, jede Zuordnung, die diese functoids verwendet, in eine kleine Assembly einzufügen. Verweisen Sie dann auf diese Assembly. Verwenden Sie das folgende Diagramm, um zu bestimmen, welche functoids Inlineskripts und welche functoids kein Inlineskript verwenden.

In der zweiten Spalte bedeutet Ja , dass dies functoid als Inlineskript implementiert ist und dazu führt System.Byte[] , dass Objekte im Arbeitsspeicher gesammelt werden. Nein bedeutet, dass dies functoid nicht als Inlineskript implementiert ist und keine System.Byte[] Objekte im Arbeitsspeicher sammeln.

Funktoide Inlineskript?
Alle Zeichenfolgen-Funktoide Ja
Alle mathematischen Funktoide Ja
Alle logischen Funktoide mit Ausnahme von IsNil Ja
Funktoid Logisches Isnil Nein
Alle Funktoide "Datum/Uhrzeit" Ja
Alle Konvertierungsfunktoide Ja
Alle wissenschaftlichen Funktoide Ja
Alle kumulativen Funktoide Ja
Alle Datenbank-Funktoide Nein
Erweiterte Funktoide Inlineskript?
Funktoid "Schleifen" Nein
funktoid Value-Mapping Flattening Nein
Funktoid Assert Nein
Funktoid "Tabellenextraktor" Nein
Funktoid "Tabellenschleifen" Nein
Skripterstellungs-Funktoid mit Inline C# Ja
Funktoid "Skripterstellung" mit Inline-JScript.NET Ja
Skripterstellungs-Funktoid mit Inline-Visual Basic .NET Ja
Skripterstellungs-Funktoid mit Inline-XSLT Nein
Skriptfunktions-Funktoid mit Inline-XSLT-Aufrufvorlage Nein
Skripterstellungs-Funktoid, das externe Assembly aufruft Nein
Funktoid "Nilwert" Nein
Funktoid "Wertzuordnung" Nein
Funktoid "Massenkopie" Nein
Funktoid Iteration Nein
Funktoid Index Nein
Funktoid "Datensatzanzahl" Nein

BizTalk Server 2006 und höheren Versionen verbessern die Speicherverwaltung für große Dokumente erheblich. Dazu implementiert BizTalk Server einen konfigurierbaren Schwellenwert für die Nachrichtengröße für das Laden von Dokumenten in den Arbeitsspeicher während Transformationsvorgängen. Der Standardschwellenwert für die Nachrichtengröße beträgt 1 MB. Weitere Informationen zur Einstellung TransformThreshold finden Sie unter How BizTalk Server Processes Large Messages(Wie BizTalk Server große Nachrichten verarbeitet).

Große Attributwerte und große Elementwerte

Wenn BizTalk Server eine Empfangs- oder Sendepipeline für ein XML-Dokument ausführt, wird die Nutzlast im Arbeitsspeicher verarbeitet, wenn das Dokument eine oder mehrere der folgenden Entitäten enthält:

  • Große Attributwerte
  • Große Elementwerte
  • Große Attribut- oder Elementtags

Um dieses Problem zu beheben, beschränken Sie die Größe dieser Entitäten. Wenn diese Methode nicht möglich ist, stellen Sie sicher, dass Ihr BizTalk HOST-instance nicht mehrere Dokumente wie diese gleichzeitig verarbeitet.

Benutzerdefinierte Pipelinekomponenten

Sie verwenden eine benutzerdefinierte Pipelinekomponente, die den gesamten Stream in den Arbeitsspeicher lädt. Alle Komponenten, die in BizTalk Server enthalten sind, mit Ausnahme von Transformationen, unterstützen Streaming. Diese Komponenten verbrauchen während des Streamings nicht so viel Arbeitsspeicher. Benutzerdefinierte Pipelinekomponenten unterstützen jedoch möglicherweise kein Streaming.

Streaming unter starker Belastung

Sendehosts haben nicht genügend Arbeitsspeicher, wenn sie unter hoher Belastung arbeiten. BizTalk Server sendet Pipelines und Adapter, die Streaming unterstützen. Beim Streaming lädt jede Komponente ein kleines Fragment des Datenstroms in den Arbeitsspeicher. Da jede Nachricht andere Datenstrukturen zusammen mit einem Nachrichtenkontext enthält, der signifikant oder klein sein kann, wirkt sich dieses Verhalten auf das Verhalten von BizTalk Server unter starker Belastung aus.

Das Verhalten von BizTalk Server ist betroffen, da die Engine eine vorkonfigurierte Anzahl von Nachrichten lädt. Die Anzahl der Nachrichten, die die Engine lädt, basiert auf den Werten, die im Feld LowWaterMark und im Feld HighWaterMark der Adm_serviceClass Tabelle angezeigt werden. Die Adm_serviceClass Tabelle befindet sich in der BizTalk-Verwaltungsdatenbank. Diese Werte steuern die Anzahl der Nachrichten, die BizTalk Server gleichzeitig verarbeitet oder sendet.

Der HighWaterMark-Wert ist die Gesamtzahl der Nachrichten, die die Engine gleichzeitig verarbeitet. Der Standardwert ist 200 Nachrichten pro CPU. Daher versucht der Sendehost auf einem Server mit 8 Prozessoren, 1.600 Nachrichten (200 * 8) gleichzeitig zu verarbeiten.

Wenn Sie davon ausgehen, dass jede Nachricht 50 KB groß ist, entsprechen die Nachrichten 80 MB (1.600 * 50=80.000 KB).

Um dieses Problem zu beheben, können Sie den HighWaterMark-Wert und den LowWaterMark-Wert in der Datenbank ändern. Welche Werte Sie verwenden, hängt von der Größe der Nachrichten ab. Für BizTalk Server 2006 und höhere Versionen können Sie die Standardeinstellungen für die Hostdrosselung ändern.

Versuchen Sie, das Problem zu vereinfachen

Wenn Sie einen Speicherverlust erkannt haben, versuchen Sie, die Ursache zu ermitteln, indem Sie benutzerdefinierte Komponenten entfernen oder eine Zuordnung vereinfachen. Versuchen Sie außerdem, das Problem mithilfe einer einfachen Orchestrierung oder einer einfachen Lösung zu reproduzieren. In der Regel sollten Sie separate Empfangshosts für Empfangsadapter erstellen. Sie sollten auch separate Sendehosts für Sendeadapter erstellen. Wenn Sie diese Methode verwenden, kann jeder Adapter in einem separaten Prozess ausgeführt werden. Daher wissen Sie, welche Komponenten beteiligt sind, wenn ihr BizTalk Server Prozess nicht genügend Arbeitsspeicher aufweist.

Schritte zur Problembehandlung

Verwenden Sie zum Beheben von Problemen mit nicht genügend Arbeitsspeicher das Debugdiagnosetool, um die Speicherbelegungen im Laufe der Zeit zu überwachen. Das Debugdiagnosetool kann eine Speicherverlust-Speicherabbilddatei (.dmp) erstellen und analysieren. Wenn Sie Speicherverluste beheben, besteht das Ziel darin, Leaktrack.dll anzufügen, bevor sich die Hohe Arbeitsspeicherbedingung reproduziert, um die Arbeitsspeichervergrößerung im Laufe der Zeit zu erfassen. Leaktrack.dll ist im Debugdiagnosetool enthalten.

  1. Installieren Sie das Debugdiagnosetool.

    Die folgende Datei steht im Microsoft Download Center zum Download zur Verfügung:
    Jetzt das Debugdiagnosetool-Paket herunterladen

    Weitere Informationen zum Herunterladen von Microsoft-Supportdateien finden Sie unter Abrufen von Microsoft-Supportdateien von Onlinedienste.

    Microsoft hat diese Datei auf Viren überprüft. Microsoft verwendete die aktuellste Virenerkennungssoftware, die zum Zeitpunkt der Veröffentlichung der Datei verfügbar war. Die Datei wird auf Servern mit verbesserter Sicherheit gespeichert, die nicht autorisierte Änderungen an der Datei verhindern.

  2. Verwenden Sie Leistungsmonitor, um Daten zur Systemleistung zu sammeln. Diese Daten können wichtige Indikatoren für die Effizienz Ihrer BizTalk Server-Umgebung liefern. Ziel ist es, die Prozessleistung im Laufe der Zeit zu erfassen. Aktivieren Sie daher Leistungsmonitor Protokollierung, bevor der Speicherverlust auftritt.

Verwenden der Leistungsmonitor-Protokollierung

In den folgenden Abschnitten wird die Verwendung der Leistungsmonitorprotokollierung beschrieben.

Auswählen der zu protokollierenden Daten

Um die zu protokollierenden Daten auszuwählen, verwenden Sie die methode, die für Ihr Betriebssystem geeignet ist:

  • Für Windows Server 2008 und Windows Server 2008 R2

    1. Öffnen Sie unter Verwaltung die Option Zuverlässigkeit und Leistungsmonitor.

    2. Klicken Sie mit der rechten Maustaste auf Leistungsmonitor, klicken Sie auf Neu, und klicken Sie dann auf Datensammlersatz.

    3. Geben Sie im Feld Name einen beschreibenden Namen ein, und klicken Sie dann auf Weiter.

    4. Notieren Sie sich das Stammverzeichnis , und klicken Sie dann auf Weiter.

    5. Klicken Sie auf Diesen Datensammlersatz jetzt starten, und klicken Sie dann auf Fertig stellen.

    6. Erweitern Sie Datensammlersätze, erweitern Sie Benutzerdefiniert , und wählen Sie dann Ihre Datei aus.

    7. Klicken Sie mit der rechten Maustaste auf Systemmonitorprotokoll, und klicken Sie dann auf Eigenschaften.

    8. Klicken Sie auf der Registerkarte Leistungsindikatoren auf Hinzufügen. Wählen Sie die folgenden Objekte aus, und klicken Sie dann auf Hinzufügen, nachdem Sie die einzelnen Objekte ausgewählt haben:

      • .NET CLR-Ausnahmen
      • .NET CLR-Arbeitsspeicher
      • BizTalk: Messaging
      • BizTalk: TDDS
      • Arbeitsspeicher
      • Prozess
      • Prozessor
      • XLANG/s-Orchestrierungen

      Wenn SQL Server lokal ist, fügen Sie auch die folgenden Objekte hinzu:

      • SQLServer: Datenbanken
      • SQLServer: Allgemeine Statistiken
      • SQLServer: Speicher-Manager

    9. Klicken Sie auf OK.

    10. Ändern Sie das Feld Beispielintervall in5 Sekunden.

      Hinweis

      Der Wert des Beispielintervalls und die Startzeit für die Überwachung sind subjektiv. Diese Werte hängen davon ab, wann der Speicherverlust reproduziert wird. Da die Protokolldatei groß sein kann, geben Sie ein Intervall an, in dem Sie die erforderlichen Informationen abrufen können, ohne den Server zu überfordern.

    11. Klicken Sie auf OK.

Um das Sammeln von Daten zu beenden, klicken Sie im Menü Aktion auf Beenden.

  • Für Windows Server 2003 oder Windows XP

    1. Erweitern Sie Leistungsprotokolle und Warnungen.

    2. Klicken Sie mit der rechten Maustaste auf Indikatorenprotokolle, und klicken Sie dann auf Neue Protokolleinstellungen. Das Dialogfeld Neue Protokolleinstellungen wird angezeigt.

    3. Geben Sie im Feld Name einen beschreibenden Namen ein, und klicken Sie dann auf OK.

    4. Notieren Sie sich den Speicherort der Protokolldatei. (Sie können auch auf die Registerkarte Protokolldateien und dann auf Konfigurieren klicken, um den Speicherort der Protokolldatei zu ändern.)

    5. Klicken Sie auf Indikatoren hinzufügen.

    6. Wählen Sie Alle Leistungsindikatoren und Alle Instanzen aus.

    7. Wählen Sie in der Liste Leistungsobjekt die folgenden Objekte aus. Klicken Sie auf Hinzufügen , nachdem Sie die einzelnen Objekte ausgewählt haben.

      • .NET CLR-Ausnahmen
      • .NET CLR-Arbeitsspeicher
      • BizTalk: Messaging
      • BizTalk: TDDS
      • Arbeitsspeicher
      • Prozess
      • Prozessor
      • XLANG/s-Orchestrierungen

      Wenn SQL Server lokal ist, fügen Sie auch die folgenden Objekte hinzu:

      • SQLServer: Datenbanken
      • SQLServer: Allgemeine Statistiken
      • SQLServer: Speicher-Manager

    8. Klicken Sie auf Schließen.

    9. Ändern Sie den Wert im Datenstichprobenintervall in 5 Sekunden.

      Hinweis

      Der Wert des Datensamplingintervalls und die Zeit, zu der die Überwachung gestartet werden soll, sind subjektiv. Diese Werte hängen davon ab, wann der Speicherverlust reproduziert wird. Da die Protokolldatei groß sein kann, geben Sie ein Intervall an, in dem Sie die erforderlichen Informationen abrufen können, ohne den Server zu überfordern.

    10. Klicken Sie auf OK. Um die Erfassung von Daten zu beenden, klicken Sie mit der rechten Maustaste auf den Namen des Indikatorprotokolls, und klicken Sie dann auf Beenden.

Abrufen der Speicherabbilddatei

Verwenden Sie eine der folgenden Methoden, um die Speicherabbilddatei abzurufen:

Methode 1: Automatisch

Das Erstellen einer Speicher- und Behandlungsleckregel mit DebugDiag ist der empfohlene Ansatz zum Erfassen eines Speicherabbilds. Die Regel für Arbeitsspeicher- und Verarbeitungsverluste fügt automatischLeaktrack.dllan. Dies wird verwendet, um Speicherbelegungen nachzuverfolgen. Führen Sie die folgenden Schritte aus, um die Regel arbeitsspeicher- und verarbeitungsverlust zu erstellen:

  1. Starten Sie das Debugdiagnosetool 1.1.

  2. Wählen Sie Arbeitsspeicher und Verlust behandeln aus, und klicken Sie dann auf Weiter.

  3. Wählen Sie den Btsntsvc.exe Prozess aus, und klicken Sie dann auf Weiter.

  4. Führen Sie auf der Seite Leckregel konfigurieren die folgenden Schritte aus:

    1. Aktivieren Sie das Kontrollkästchen Speichernachverfolgung sofort starten, wenn die Regel aktiviert ist . Andernfalls können Sie eine Aufwärmzeit angeben, bevor LeakTrack.dll in den BTSNTSvc.exe Prozess eingefügt wird.

    2. Klicken Sie auf Konfigurieren, und führen Sie dann die folgenden Schritte aus:

      • Vergewissern Sie sich, dass Die Option Absturzregel automatisch erstellen ausgewählt ist. Wenn Sie diese Option auswählen, wird automatisch ein Speicherabbild erstellt, wenn der BTSNTSvc.exe Prozess beendet wird.

      • Aktivieren Sie das Kontrollkästchen Benutzerdump generieren, wenn virtuelle Bytes erreichen , und behalten Sie den Standardwert 1024 bei.

      • Aktivieren Sie das Kontrollkästchen und jedes weitere Kontrollkästchen, und behalten Sie den Standardwert 200 bei. Wenn Sie die Option virtuelle Bytes erreichen auswählen, wird automatisch ein Speicherabbild erstellt, wenn virtuelle Bytes 1024 MB verwenden. Wenn virtuelle Bytes um 200 MB zunimmt, wird automatisch ein weiteres Speicherabbild erstellt.

    3. Klicken Sie auf Speichern und schließen.

    4. Klicken Sie auf Weiter.

    5. Klicken Sie auf der Seite Speicherabbildspeicherort und Regelname auswählen auf Weiter.

      Hinweis

      Sie können den Pfad der Speicherabbilddatei auch im Feld Userdump Location (Userdump-Speicherort ) auf dieser Seite ändern.

    6. Klicken Sie auf Fertig stellen , um die Regel jetzt aktiv zu machen.

      Hinweis

      Die Regel status jetzt Nachverfolgung. Jedes Mal, wenn ein Speicherabbild erstellt wird, erhöht sich der Wert in der Spalte Userdump Count auf der Registerkarte Regeln . Der Standardspeicherspeicherspeicherspeicherort ist C:\Program Files\DebugDiag\Logs.

Methode 2: Manuell

Sie können Leaktrack.dll auch manuell anfügen und die Speicherabbilddatei manuell abrufen. Dadurch können Sie steuern, wann das Speicherabbild erstellt wird. Gehen Sie dazu wie folgt vor:

  1. Starten Sie das Debugdiagnosetool 1.1.
  2. Klicken Sie auf die Registerkarte Prozesse.
  3. Klicken Sie mit der rechten Maustaste auf den Btsntsvc.exe Prozess, und klicken Sie dann auf Auf Lecks überwachen.
  4. Klicken Sie im Dialogfeld Debugdiagnosetool auf Ja und dann auf OK.

Create eine Absturzregel, um denselben Btsntsvc.exe Prozess zu überwachen, falls der Prozess beendet wird, bevor Sie das Speicherabbild erstellen können:

  1. Starten Sie das Debugdiagnosetool 1.1.
  2. Wählen Sie Absturz aus, und klicken Sie dann auf Weiter.
  3. Wählen Sie einen bestimmten Prozess aus, und klicken Sie dann auf Weiter.
  4. Wählen Sie denselben Btsntsvc.exe Prozess aus, und klicken Sie dann auf Weiter.
  5. Klicken Sie auf der Seite Erweiterte Konfiguration (optional) auf Weiter.
  6. Klicken Sie im Dialogfeld Speicherabbildspeicherort und Regelname auswählen (optional) auf Weiter.
  7. Wählen Sie Regel jetzt aktivieren aus, und klicken Sie dann auf Fertig stellen.

Wenn der Prozess 60 bis 80 Prozent des RAM erreicht, klicken Sie mit der rechten Maustaste auf den Btsntsvc.exe Prozess, und klicken Sie dann auf Create Vollständiger Benutzerdump. Wenn der BizTalk-Prozess beendet wird, bevor Sie das Benutzerabbild erstellen können, sollte die Absturzregel wirksam werden und das Speicherabbild erstellen.

Beenden Leistungsmonitor Protokollierung

Wenn Sie ein Speicherabbild erfassen und Daten Leistungsmonitor, beenden Sie Leistungsmonitor Protokollierung etwa zwei Minuten nach der Erstellung des Speicherabbilds.

Analysieren der Speicherabbilddatei

Um die Ursache eines Speicherverlusts zu ermitteln, können Sie das Debugdiagnosetool verwenden, um die Speicherabbilddatei zu analysieren. Gehen Sie dazu wie folgt vor:

  1. Klicken Sie auf die Registerkarte Erweiterte Analyse .
  2. Klicken Sie auf Datendateien hinzufügen, und suchen Sie dann die .dmp Datei.
  3. Wählen Sie das Skript Speicherauslastungsanalyse aus, und klicken Sie dann auf Analyse starten.

Standardmäßig wird eine Analyseberichtsdatei (die MHT-Datei) im C:\Program Files\DebugDiag\Reports Ordner erstellt, wenn die Analyse abgeschlossen ist. Die Berichtsdatei wird auch in Ihrem Browser angezeigt. Die Berichtsdatei enthält die Ergebnisse der Analyse. Darüber hinaus kann die Berichtsdatei Empfehlungen zum Beheben des Speicherverlusts enthalten.

Wenn Sie benutzerdefinierte DLLs verwenden, können Sie den Symbolpfad der benutzerdefinierten PDB-Dateien zur Analyse hinzufügen. Gehen Sie dazu wie folgt vor:

  1. Öffnen Sie das Debugdiagnosetool.
  2. Klicken Sie im Menü Extras auf Optionen und Einstellungen.
  3. Geben Sie im Feld Symbol Search Pfad zum Debuggen den Symbolpfad ein.

Wenn Sie Hilfe beim Analysieren der Speicherabbilddatei benötigen, wenden Sie sich an den Microsoft-Kundendienst. Eine vollständige Liste der Telefonnummern des Kundendiensts und Informationen zu Den Supportkosten finden Sie unter Support kontaktieren.

Bevor Sie sich an den Kundendienst wenden, komprimieren Sie die Speicherabbilddatei, das Leistungsmonitor-Protokoll, die Analyseberichtsdatei und die aktualisierten Ereignisprotokolle (EVT-Dateien). Möglicherweise müssen Sie diese Dateien an einen BizTalk Server Supporttechniker senden.