Freigeben über

Fehlerbehebung eines Speicherlecks oder einer Out-of-Memory-Exception im BizTalk Server-Prozess

In diesem Artikel wird beschrieben, wie Sie probleme mit einem Speicherverlust oder einer Ausnahme außerhalb des Arbeitsspeichers im BizTalk Server-Prozess von Microsoft BizTalk Server beheben.

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

Übersicht

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 (Out-of-Memory) in Microsoft BizTalk Server zu finden. In diesem Artikel werden wichtige Punkte erläutert, die Sie berücksichtigen sollten, wenn Sie die Speicherauslastung und mögliche speicherbezogene Probleme auswerten. Zu diesen Überlegungen gehören die folgenden Punkte:

  • Physischer RAM
  • Große Nachrichtenverarbeitung
  • Verwendung des Schalters "/3 GB"
  • Verwendung von benutzerdefinierten Komponenten
  • Welche Version von Microsoft .NET Framework das System ausführt
  • Die Anzahl der Prozessoren

Der BizTalk Server-Prozess kann einen Speicherverlust feststellen, wenn die Speicherauslastung in Microsoft Windows Task Manager mehr als 50 Prozent des physischen RAM verbraucht. Ein Speicherleck kann zu einer Out-of-Memory-Ausnahme führen, wenn die Arbeitsspeicherauslastung steigt, bis der Prozess keinen Systemspeicher mehr hat oder bis der Prozess nicht mehr funktioniert. Beachten Sie für dieses Problem Folgendes:

Physische RAM- und Speicherauslastung

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 über 4 Gb RAM verfügt und der BizTalk Server-Prozess etwa 500 MB RAM verwendet, liegt möglicherweise kein Verlust vor. Wenn der BizTalk Server-Prozess etwa 1 GB RAM verwendet, liegt möglicherweise ein Speicherverlust oder eine hohe Speichersituation vor. Der Speicherverbrauch kann durch eine lang laufende gespeicherte Prozedur oder eine Orchestrierung 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 Arbeitsspeicherbedingung auftritt.

Umfangreiche 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 Arbeitsspeicher.

Beachten Sie außerdem, dass eine hohe Speicherauslastung möglicherweise erwartet wird, 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, um den Speicherverlust zu reproduzieren

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

Verwendung des Schalters "/3 GB" auf 32-Bit-Computern

In der Regel kann ein Prozess auf 2 GB virtuellen Adressraum zugreifen. Der Switch "/3GB" ist eine Option für Systeme, die mehr adressierbaren Arbeitsspeicher erfordern. Diese Option kann die Speicherauslastung für die Verarbeitung von Nachrichten verbessern. Der Switch "/3GB" ermöglicht jedoch nur 1 GB Adressspeicher für Kernelmodusvorgänge. Darüber hinaus kann dieser Switch das Risiko erhöhen, dass der Poolspeicher aufgebraucht wird.

Ist der Schalter "/3GB" in einer 32-Bit-Version von Windows aktiviert, kann der Prozess auf 3 GB virtuellen Adressraum zugreifen, sofern der Prozess einen großen Adressraum nutzen kann. Ein Prozess ist großadressiert, wenn die ausführbare Datei das IMAGE_FILE_LARGE_ADDRESS_AWARE Flag im Bildheader festgelegt hat. Da der BizTalk-Prozess großadressfähig ist, kann BizTalk von der Option "/3GB" profitieren.

Wenn eine 32-Bit-BizTalk-Hostinstanz auf einer 64-Bit-Version von Windows (AMD64) ausgeführt wird, profitiert der BizTalk-Prozess vom 4-GB-Speicherspeicherplatz, da BizTalk groß adressfähig ist. Daher ist das Verschieben Ihrer Anwendungen mit hohem Arbeitsspeicher auf einen 64-Bit-Server die beste Lösung.

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

Sie sollten auch die virtuellen Bytes und die privaten Bytes berücksichtigen, die vom Prozess verwendet werden. Eine BizTalk-Hostinstanz (bei der es sich um eine .NET Framework-Anwendung handelt) kann einen Speicherfehler erhalten, bevor der Wert für "Virtuelle Bytes" 2 GB erreicht. Diese Situation kann auftreten, obwohl der maximale adressierbare Speicher durch einen Prozess in einer 32-Bit-Version von Windows (ohne den Schalter /3GB) 2 GB beträgt. Eine Erläuterung dazu, warum diese Situation auftreten kann, finden Sie auf der folgenden MSDN-Website (Microsoft Developer Network):
ASP.NET Leistungsmonitor ing und wann Administratoren benachrichtigt werden sollen

Der Switch "/3 GB" erhöht auch die maximale private Byte des BizTalk-Prozesses von 800 MB auf 1800 MB. Weitere Informationen zur .NET Framework-Anwendungsleistung mit aktivierter Option "/3GB" finden Sie in Kapitel 17 – Optimierung der .NET-Anwendungsleistung.

In der folgenden Tabelle sind diese Informationen zusammengefasst und enthalten die praktischen Grenzwerte für virtuelle Bytes und private Bytes.

Prozess Fenster Adressierbarer Speicher (mit einem großen adressierbaren Prozess) Praktische Grenze für virtuelle Bytes Praktische Grenze für private Bytes
32 Bit 32 Bit 2 GB 1400 MB 800 MB
32 Bit 32-Bit mit /3GB 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 Speicher für 32-Bit- und 64-Bit-Windows finden Sie unter "Speicherbeschränkungen für Windows- und Windows Server-Versionen".

In der folgenden Tabelle sind die PAE- und 3-GB-Unterstützung 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 Switch "/3GB" aktivieren müssen, um die Leistungsanforderungen eines Computers zu erfüllen, auf dem BizTalk Server ausgeführt wird, sollten Sie erwägen, der BizTalk-Gruppe Server hinzuzufügen. Auf diese Weise können Sie die speicherintensiven Hostinstanzen skalieren.

BizTalk-Komponenten, die innerhalb eines Internetinformationsdienste -Prozesses (IIS) ausgeführt werden, können auch von Vorteil sein, wenn der Switch "/3 GB" aktiviert ist.

Der Switch "/3 GB" wird auf Computern, auf denen Windows SharePoint Services 2.0 oder höher ausgeführt wird, oder auf SharePoint Portal Server 2003 SP2 oder höheren Versionen nicht unterstützt. Der Switch "Windows Server 2003 /3GB" 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.

Verwendung 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 an die Microsoft .NET Framework-Klasse XslTransform innerhalb des BizTalk-Prozesses.

Ein weiteres häufiges Problem tritt auf, wenn intensive Zeichenfolgenmanipulation stattfindet. Intensive Zeichenfolgenmanipulation kann viel Speicher verbrauchen. Weitere Informationen zu Möglichkeiten zur Leistungsverbesserung finden Sie unter "Verbessern der Leistung von verwaltetem Code".

Version von .NET Framework

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

Anzahl der Prozessoren

Die Common Language Runtime (CLR) weist die folgenden Garbage Collectors (GCs) auf:

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

Wenn der Computer, auf dem BizTalk Server ausgeführt wird, ein Multiprozessorsystem ist, verwendet .NET Framework die Serverversion des Ausführungsmoduls. Dies ist die Standardeinstellung. Der Server-Garbage-Collector ist für maximalen Durchsatz ausgelegt. Darüber hinaus skaliert der Server-Garbage-Collector, um eine hohe Leistung zu bieten. Dieser Garbage Collector weist Arbeitsspeicher zu und gibt später Arbeitsspeicher frei, um eine hohe Leistung auf dem System bereitzustellen. 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 dem Computer der Systemspeicher ausgeht oder der Prozess aufgrund unzureichenden adressierbaren Arbeitsspeichers nicht mehr funktioniert, kann ein Speicherleck vorliegen.

Wenn der Computer, auf dem BizTalk Server ausgeführt wird, ein einzelnes Prozessorsystem ist, verwendet .NET Framework die Workstation-Version des Ausführungsmoduls. Es ist das Standardverhalten. Der Garbage Collector-Zuordnungsalgorithmus der Workstation wurde nicht für die Skalierung oder für den maximalen Durchsatz entwickelt. Dieser Speicherbereiniger verwendet konkurrierende Speicherbereinigungsmethoden. Diese Methoden sind für Anwendungen konzipiert, die komplexe Benutzeroberflächen aufweisen. 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. Es können jedoch schwerwiegende Probleme auftreten, wenn Sie die Registrierung falsch ändern. Stellen Sie daher sicher, dass Sie diese Schritte sorgfältig ausführen. Für weiteren Schutz sichern Sie die Registrierung, bevor Sie sie ändern. Anschließend können Sie die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter: Sichern und Wiederherstellen der Registrierung Windows.

Manchmal kann es sinnvoll sein, die Workstation-Version des Ausführungsmoduls auf einem Multiprozessorsystem auszuführen. Sie können den folgenden Registrierungsschlüssel verwenden, um zur Workstation-Version des Ausführungsmoduls zu wechseln.

BizTalk 2006 und höhere Versionen

Erstellen Sie den folgenden CRL Hosting Zeichenfolgenregistrierungsschlüssel mit den entsprechenden Werten:

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

BizTalk 2004

Erstellen Sie den folgenden CRL Host Zeichenfolgenregistrierungsschlüssel mit den entsprechenden Werten:

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

Weitere Informationen finden Sie unter Leistungsüberlegungen für Laufzeittechnologien in .NET Framework.

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

Drosselungsschwellenwerte für die Nutzung des Prozessor- und physischen Arbeitsspeichers

In BizTalk Server 2006 und späteren Versionen können die Schwellenwerte für die Prozessespeicherauslastung und die Begrenzung der physischen Speicherauslastung geändert werden.

  • Standardmäßig ist der Schwellenwert für die Einschränkung der Prozessspeicherauslastung auf 25 festgelegt. Wenn dieser Wert überschritten wird und die Speicherauslastung des BizTalk-Prozesses mehr als 300 MB beträgt, kann ein Drosselungszustand 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 mehr Arbeitsspeicherverbrauch durch den BizTalk-Prozess, bevor die Drosselung erfolgt.

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

Dehydrations-Drosselungsschwellen

Die standardmäßigen Schwellenwerte für die Speicher-Dehydration können zu einer übermäßigen Dehydration führen, wenn Orchestrierungen auf einem 64-Bit-Host ausgeführt werden. Weitere Informationen zu diesem Problem finden Sie unter "Dehydrierungsstandardeigenschaften".

Notiz

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

Bei gleichwertiger Hardware in einer 32-Bit-Hostinstanz ist die beobachtete Dehydrierung gering, wenn die gleichen Orchestrierungen unter Verwendung der standardmäßigen Drosselschwellenwerte für Speicherdehydrierung ausgeführt werden.

Da die 64-Bit-Architektur erweiterten Speicheradressraum (16 TB anstelle von 4 GB) bereitstellt, werden 64-Bit-Hostinstanzen mehr Arbeitsspeicher zugewiesen als 32-Bit-Hostinstanzen. Dies kann dazu führen, dass die Standardmäßigen Speichereinschränkungsschwellenwerte überschritten werden.

Um dieses Verhalten zu umgehen, ändern Sie die Werte "VirtualMemoryThrottlingCriteria" und "PrivateMemoryThrottlingCriteria" in der Datei "BTSNTSvc64.exe.config". Verwenden Sie die Indikatoren \Process\Virtual Bytes und \Process\Private Bytes Leistungsmonitor, um die größte Menge an Arbeitsspeicher zu ermitteln, die von einer Orchestrierungsinstanz zugewiesen wird.

  • Legen Sie den OptimalUsage-Wert für beide Eigenschaften basierend auf den folgenden Eigenschaften fest:

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

  • Festlegen von MaximalUsage für beide Eigenschaften auf den OptimalenUsage-Wert + 30 %

Beispielsweise, wenn der Leistungsindikatorwert für den \Process\Virtuellen Byte Leistungsmonitor einer Orchestrierungsinstanz 5.784.787.695 Bytes (5.517 MB) beträgt, legen Sie den OptimalUsage-Wert für VirtualMemoryThrottlingCriteria auf 6.363 MB fest (5.784.787.695 * 1,10 = 6.363.266.464,5 Bytes).

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

Wenn der Indikatorwert des \Process\Private Bytes Leistungsmonitor 435689400 Bytes (415 MB) ist, legen Sie den Optimalen Nutzungswert für PrivateMemoryThrottlingCriteria auf 457 MB (435689400 * 1,10 = 479258340 Bytes) fest.

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

In diesem Beispiel werden die folgenden Werte in der Datei BTSNTSvc64.exe.config angegeben, um die Drosselung zu verringern.

Performance-Monitor-Zähler Zugeordneter Arbeitsspeicher Optimale Nutzung Maximalverwendung
\Prozess\Virtuelle Bytes 5.784.787.695 Bytes (5517 MB) 6069 7889
\Prozess\Private Bytes 435.689.400 Bytes (415 MB) 457 594

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

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

Um zu ermitteln, welche Hostinstanz die Orchestrierung ausführt, können Sie den ID-Prozess aus dem \BizTalk: Messaging\ID Process und \Process\ID Process Leistungsmonitor Indikatoren abgleichen. Überprüfen Sie dann den Mittelwert, der für die entsprechenden \Process\Virtual Bytes und \Process\Private Bytes-Zähler des Leistungsmonitors angezeigt wird.

Notiz

Informationen, die der Benutzer beachten sollte, auch wenn sie überspringtDie hohe Dehydrierung kann zu einer erheblichen Leistungsminderung führen, wenn die BizTalkMsgBoxDb Datenbank auf SQL Server 2008 ausgeführt wird.

BizTalk Server Service Packs und kumulative Updates

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

Heap-Decommit-Freier-Block-Schwellenwert

Der Registrierungsschlüsselwert ist standardmäßig HeapDeCommitFreeBlockThreshold 0. Ein Wert von 0 bedeutet, dass der Heap-Manager jede verfügbare 4-Kilobyte-Seite dekommittiert. De-Commit-Vorgänge können zu einer Fragmentierung des virtuellen Speichers führen. Die Größe des HeapDeCommitFreeBlockThreshold Parameters im Heap-Manager hängt von der Art der Aufgaben 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 ist systemweit. Daher verwenden die meisten Prozesse mehr Arbeitsspeicher beim Start.
  • 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 Einstellungen 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 (Es ist der empfohlene Startwert.)
  • Standardwert: nicht vorhanden

Transformationsoperationen

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

Sie können dieses Problem mit einer der folgenden Methoden beheben:

  • Verringern 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 Karte ein Skript functoid enthält, das Inline C# (oder eine andere Inlinesprache) verwendet, wird die Assembly im Arbeitsspeicher erstellt. Das System.Policy.Security.Evidence-Objekt verwendet das Objekt der Assembly, die den Aufruf tätigt. Diese Situation erstellt ein gewurzeltes Objekt, das erst gelöscht wird, wenn der BizTalk-Dienst neu gestartet wird.

Die meisten Standard-BizTalk functoids werden als Inline-Skript implementiert. Diese Elemente können dazu führen, dass System.Byte[] Objekte sich im Arbeitsspeicher ansammeln. Um die Speicherauslastung zu minimieren, empfehlen wir, jede Karte, die diese functoids verwendet, in einer kleinen Assembly zu platzieren. Verweisen Sie dann auf diese Assembly. Verwenden Sie das folgende Diagramm, um zu bestimmen, welche functoids Inlineskripte verwenden und welche functoids keine Inlineskripte verwenden.

In der zweiten Spalte bedeutet Yes, dass dieses Element als Inlineskript implementiert wird und dass es dazu führt, dass functoid-Objekte im Arbeitsspeicher gesammelt werden. Nein bedeutet, dass dies functoid nicht als Inlineskript implementiert ist und nicht dazu führt System.Byte[] , dass Objekte im Arbeitsspeicher erfasst werden.

Funktionsobjekte Inlineskript?
Alle String-Functoids Ja
Alle mathematischen Funktoiden Ja
Alle logischen Funktoiden mit Ausnahme von IsNil Ja
Logische IsNil-Funktoid Nein
Alle Datum-/Zeit-Funktionen Ja
Alle Konvertierungs-Funktoiden Ja
Alle wissenschaftlichen Funktionsmodule Ja
Alle kumulierten Funktoiden Ja
Alle Datenbank-Funktionsbausteine Nein
Erweiterte Funktoide Inlineskript?
Schleifenfunktiod Nein
Wertzuordnung flacher Functoid Nein
Funktoid „Assert“ Nein
Funktoid „Tabellen extrahieren“ Nein
Funktoid für Tabellenschleifen Nein
Skript-Funktor mit Inline C# Ja
Skript-Functoid mit Inline-JScript.NET Ja
Skript-Functoid mit Inline-Visual Basic .NET Ja
Functoid-Skripten mit Inline-XSLT Nein
Scripting-Functoid mit Inline-XSLT-Vorlage für Aufrufe Nein
Skript-Functoid ruft externe Assembly auf Nein
Funktoid „Nullwert“ Nein
Wertzuordnungsfunktioid Nein
Funktionselement „Massenkopie“ Nein
„Iteration“ Funktoid Nein
Funktoid „Index“ Nein
Funktoid „Datensatzanzahl“ Nein

BizTalk Server 2006 und höhere Versionen verbessern die Speicherverwaltung für große Dokumente erheblich. Dazu implementiert BizTalk Server einen konfigurierbaren Schwellenwert für die Nachrichtengröße zum 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".

Große Attributwerte und große Elementwerte

Wenn BizTalk Server eine Empfangspipeline oder eine Sendepipeline in einem 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 Ihre BizTalk HOST-Instanz nicht mehrere Dokumente wie diese gleichzeitig verarbeitet.

Benutzerdefinierte Pipelinekomponenten

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

Streaming unter schwerem Stress

"Send-Hosts geraten unter starken Stress und haben dann nicht genügend Arbeitsspeicher." BizTalk Server sendet Pipelines und sendet Adapter, die Streaming unterstützen. Im 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 schwerem Stress aus.

Das Verhalten von BizTalk Server ist betroffen, da das Modul eine vorkonfigurierte Anzahl von Nachrichten lädt. Die Anzahl der Nachrichten, die das Modul 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 verarbeitet oder gleichzeitig sendet.

Der HighWaterMark-Wert ist die Gesamtanzahl der Nachrichten, die das Modul gleichzeitig verarbeitet. Der Standardwert ist 200 Nachrichten pro CPU. Daher versucht der Sendehost auf einem 8-Prozessor-Server, 1.600 Nachrichten (200 * 8) gleichzeitig zu verarbeiten.

Wenn Sie davon ausgehen, dass jede Nachricht 50 KB 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. Die von Ihnen verwendeten Werte hängen von der Größe der Nachrichten ab. Für BizTalk Server 2006 und höhere Versionen können Sie die Standardeinstellungen für die Hosteinschränkung ändern.

Versuchen Sie, das Problem zu vereinfachen

Wenn Sie einen Speicherverlust identifiziert haben, versuchen Sie, die Ursache zu ermitteln, indem Sie benutzerdefinierte Komponenten entfernen oder eine Karte vereinfachen. Versuchen Sie außerdem, das Problem mithilfe einer einfachen Orchestrierung oder einer einfachen Lösung zu reproduzieren. Normalerweise 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. Wenn Ihr BizTalk Server-Prozess eine Speicherüberlastung aufweist, wissen Sie daher, welche Komponenten beteiligt sind.

Schritte zur Fehlersuche

Verwenden Sie das Debug-Diagnosetool, um ein Speichermangelproblem zu beheben, indem Sie Speicherzuweisungen im Laufe der Zeit überwachen. Das Debug-Diagnosetool kann eine Speicherleck-Abbilddatei (.dmp) erstellen und analysieren. Wenn Sie Speicherlecks beheben, besteht das Ziel darin, Leaktrack.dll anzuhängen, bevor die hohe Speicherauslastung reproduziert wird, um das Speicherwachstum über die 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:
    Laden Sie das Debug-Diagnosetoolpaket jetzt herunter.

    Weitere Informationen zum Herunterladen von Microsoft Support-Dateien finden Sie unter Beziehen von Microsoft Support-Dateien im Internet.

    Microsoft hat diese Datei auf Viren überprüft. Dazu wurde die neueste Software zur Virenerkennung verwendet, die zum Zeitpunkt der Bereitstellung verfügbar war. Die Datei befindet sich auf Servern mit verstärkter Sicherheit, wodurch nicht autorisierte Änderungen an der Datei weitestgehend verhindert werden.

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

So verwenden Sie die Protokollierung der Leistungsüberwachung

In den folgenden Abschnitten wird beschrieben, wie Sie die Protokollierung der Leistungsüberwachung verwenden.

Wählen Sie die zu protokollierenden Daten aus.

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

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

    1. Öffnen Sie in den Verwaltungstools den Zuverlässigkeits- 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 jetzt auf "Diesen Datensammlersatz starten" und 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 "Systemüberwachungsprotokoll", und klicken Sie dann auf "Eigenschaften".

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

      • .Net CLR-Ausnahmen
      • .Net CLR-Speicher
      • BizTalk: Messaging
      • BizTalk: TDDS
      • Gedächtnis
      • 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 " Beispielintervallwert " auf 5 Sekunden.

      Notiz

      Der Wert des Beispielintervalls und die Zeit für den Beginn der Ü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 Informationen abrufen können, die Sie benötigen, ohne den Server zu überwältigen.

    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 für Windows XP

    1. Erweitern Sie Leistungsprotokolle und Benachrichtigungen.

    2. Klicken Sie mit der rechten Maustaste auf Zählerprotokolle, 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 klicken und dann auf Konfigurieren, um den Speicherort der Protokolldatei zu ändern.)

    5. Klicken Sie auf " Leistungsindikatoren hinzufügen".

    6. Wählen Sie alle Zähler und alle Instanzen aus.

    7. Wählen Sie in der Liste "Performance-Objekt " die folgenden Objekte aus. Klicken Sie auf "Hinzufügen" , nachdem Sie jedes Objekt ausgewählt haben.

      • .Net CLR-Ausnahmen
      • .Net CLR-Speicher
      • BizTalk: Messaging
      • BizTalk: TDDS
      • Gedächtnis
      • 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 des Datensampling-Intervalls auf 5 Sekunden.

      Notiz

      Der Wert des Datensamplingintervalls und die Zeit für den Start der Ü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 Informationen abrufen können, die Sie benötigen, ohne den Server zu überwältigen.

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

Dumpdatei abrufen

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

Methode 1: Automatisch

Das Erstellen einer Speicher- und Handle-Leckage-Regel mit DebugDiag ist der empfohlene Ansatz zum Erfassen eines Speicherabbilds. Die Speicher- und Handle-Leckregel fügt automatisch Leaktrack.dll an. Dies wird verwendet, um Speicherzuweisungen nachzuverfolgen. Führen Sie die folgenden Schritte aus, um die Regel für Speicher- und Handle-Lecks zu erstellen:

  1. Starten Sie das Debugdiagnosetool 1.1.

  2. Wählen Sie "Speicher- und Handle-Leck" 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 "Konfiguration der Leckregel" die folgenden Schritte aus:

    1. Klicken Sie, um das Kontrollkästchen Speichernachverfolgung sofort starten, wenn die Regel aktiviert wird, auszuwählen. 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 "Automatisches Erstellen einer Absturzregel " ausgewählt ist. Wenn Sie diese Option auswählen, wird automatisch ein Speicherabbild erstellt, wenn der BTSNTSvc.exe Prozess beendet wird.

      • Klicken Sie, um das Kontrollkästchen "Userdump generieren" zu aktivieren, wenn virtuelle Bytes das Kontrollkästchen erreichen , und behalten Sie den Standardwert von 1024 bei.

      • Klicken Sie, um das Kontrollkästchen und jedes zusätzliche Kontrollkästchen auszuwählen und den Standardwert von 200 beizubehalten. Wenn Sie die Option für die Reichweite virtueller Bytes auswählen, wird automatisch ein Speicherabbild erstellt, wenn die virtuellen Bytes 1024 MB erreichen. Wenn virtuelle Bytes um 200 MB zunehmen, 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 'Speicherort und Regelname auswählen' auf 'Weiter'.

      Notiz

      Sie können auch den Pfad der Speicherabbilddatei im Feld "Userdump Location " auf dieser Seite ändern.

    6. Klicken Sie auf "Fertig stellen ", um die Regel jetzt zu aktivieren.

      Notiz

      Der Regelstatus ist jetzt "Nachverfolgen". Jedes Mal, wenn ein Speicherabbild erstellt wird, erhöht sich der Wert in der Spalte "Userdump Count" auf der Registerkarte "Regeln". Der Standard-Speicherabbildspeicherort ist C:\Program Files\DebugDiag\Logs.

Methode 2: Manuell

Sie können auch manuell Leaktrack.dll anfügen und die Speicherabbilddatei manuell abrufen. Auf diese Weise 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".

Erstellen Sie eine Absturzregel, um den gleichen Btsntsvc.exe-Prozess zu überwachen, bevor Sie das Speicherabbild erstellen können, falls der Prozess gestoppt wird.

  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 "Speicherort und Regelname auswählen" (Optional) auf "Weiter".
  7. Wählen Sie Die Regel jetzt aktivieren aus, und klicken Sie dann auf Fertig stellen.

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

Beenden der Leistungsüberwachung-Aufzeichnung

Wenn Sie ein Speicherabbild und Daten des Leistungsmonitors erfassen, beenden Sie das Protokollieren des Leistungsmonitors etwa zwei Minuten nach dem Erstellen des Speicherabbilds.

Analysieren Sie die 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 "Arbeitsspeicherdruckanalyse " 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 für die 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 "Symbolsuchpfad für Debugging " 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 und Informationen zu Supportkosten finden Sie unter " Support kontaktieren".

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