Problembehandlung bei einem Speicherverlust oder einer Ausnahme aufgrund von nicht genügend Arbeitsspeicher im BizTalk Server Prozess

Artikel
03/28/2022
22 Minuten Lesedauer

In diesem Artikel wird beschrieben, wie Sie im BizTalk Server Prozess von Microsoft BizTalk Server eine Problembehandlung bei einem Speicherverlust oder einer Ausnahme aufgrund eines Speicherfehlers ausführen.

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 Ausnahme für nicht genügend Arbeitsspeicher (OoM) in Microsoft BizTalk Server zu finden. In diesem Artikel werden wichtige Aspekte erläutert, die Sie berücksichtigen sollten, wenn Sie die Speichernutzung und mögliche speicherbezogene Probleme bewerten. Zu diesen Überlegungen gehören die folgenden Punkte:

Physischer RAM
Große Nachrichtenverarbeitung
Verwenden des /3GB-Switches
Verwenden von benutzerdefinierten Komponenten
Welche Version von Microsoft .NET Framework das System ausgeführt wird
Die Anzahl der Prozessoren

Bei dem BizTalk Server Prozess tritt möglicherweise ein Speicherverlust auf, wenn die Speicherauslastung in Microsoft Windows Task Manager mehr als 50 Prozent des physischen RAM verbraucht. Ein Speicherverlust kann zu einer Ausnahme außerhalb des Arbeitsspeichers führen, wenn die Speicherauslastung zunimmt, bis der Prozess nicht mehr im Systemspeicher ausgeführt wird oder bis der Prozess nicht mehr funktioniert. Berücksichtigen Sie bei diesem Problem Folgendes:

Physischer RAM und Speichernutzung

Da es möglicherweise zu erwarten ist, dass ein Prozess etwa die Hälfte des physischen RAM verwendet, verwenden Sie die Speichernutzung als Richtlinie. Wenn der BizTalk Server beispielsweise 4 GIGABYTE (GB) RAM hat und der BizTalk Server Prozess ca. 500 MB RAM verwendet, kann kein Speicherverlust auftreten. Wenn der BizTalk Server Prozess ca. 1 GB RAM verwendet, kann es zu einem Speicherverlust oder einer hohen Speichersituation kommt. Die Speicherauslastung kann durch eine lange ausgeführte gespeicherte Prozedur oder Orchestrierung verursacht werden. Stellen Sie sicher, dass Sie wissen, wie viel Arbeitsspeicher der BizTalk-Host normalerweise verwendet, um zu bestimmen, ob ein Speicherverlust oder eine hohe Speicherbedingung auftritt.

Große Nachrichten

Wenn BizTalk Server große Nachrichten verarbeitet, hat das System scheinbar einen Speicherverlust. Die Nachrichten verwenden jedoch möglicherweise eine große Menge Arbeitsspeicher.

Berücksichtigen Sie außerdem, dass eine hohe Speicherauslastung 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, um den Speicherverlust zu reproduzieren

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

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

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

Wenn der /3GB-Switch in einer 32-Bit-Version von Windows aktiviert ist, kann der Prozess auf 3 GB virtuellen Adressraum zugreifen, wenn der Prozess groß adressfähig ist. Ein Prozess ist groß adressfähig, wenn für die ausführbare Datei das IMAGE_FILE_LARGE_ADDRESS_AWARE Flag im Bildheader festgelegt ist. Da der BizTalk-Prozess groß adressfähig ist, wird BizTalk vom Schalter /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-Speicheradressraum, da BizTalk groß adressfähig ist. Daher kann es die beste Lösung sein, Ihre Anwendungen mit hohem Arbeitsspeicher auf einen 64-Bit-Server zu verschieben.

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

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) erhält möglicherweise einen Speicherfehler, bevor der Wert für virtuelle Bytes 2 GB erreicht. Diese Situation kann auftreten, auch wenn der maximal adressierbare Arbeitsspeicher eines Prozesses auf einer 32-Bit-Version von Windows (ohne den /3GB-Switch) 2 GB beträgt. Eine Erklärung dazu, warum diese Situation auftreten kann, finden Sie auf der folgenden Microsoft Developer Network (MSDN)-Website:
ASP.NET-Leistungsüberwachung und Wann Administratoren benachrichtigt werden sollen

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

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

Prozess	Windows	Adressierbarer Speicher (mit einem großen Adressierungsprozess)	Praktische Beschränkung für virtuelle Bytes	Praktische Beschränkung 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 Serverversionen.

In der folgenden Tabelle sind 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 /3GB-Switch 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 (IIS)-Prozesses ausgeführt werden, können ebenfalls von Vorteil sein, wenn der /3GB-Switch aktiviert ist.

Der /3GB-Switch wird auf Computern mit Windows SharePoint Services 2.0 oder neueren Versionen oder SharePoint Portal Server 2003 SP2 oder höher nicht unterstützt. Der Switch Windows Server 2003 /3GB wird in Windows SharePoint Services 2.0 oder in neueren Versionen oder in SharePoint Portal Server 2003 Service Pack 2 oder höher 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 Speichernutzung 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 Nachrichtendatenstrom an die Microsoft .NET Framework-Klasse XslTransform innerhalb des BizTalk-Prozesses.

Ein weiteres häufiges Problem tritt auf, wenn eine intensive Zeichenfolgenbearbeitung stattfindet. Intensive Zeichenfolgenmanipulation kann viel Spaß beanspruchen. Weitere Informationen zu Möglichkeiten zur Verbesserung der Leistung finden Sie unter "Verbessern der Leistung von verwaltetem Code".

Version des .NET Framework

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

Anzahl der Prozessoren

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

Workstation (Mscorwks.dll)
Server (Mscorsvr.dll)

Wenn der Computer, auf dem BizTalk Server ausgeführt wird, ein Multiprozessorsystem ist, verwendet das .NET Framework die Serverversion des Ausführungsmoduls. Dies ist das Standardverhalten. Der Garbage Collector des Servers ist für maximalen Durchsatz ausgelegt. Darüber hinaus wird der Garbage Collector des Servers skaliert, um eine hohe Leistung zu erzielen. Dieser Garbage Collector weist Speicher zu und gibt später Speicher frei, um eine hohe Leistung auf dem System zu gewährleisten. 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 auf dem Computer nicht mehr genügend Systemspeicher vorhanden ist oder der Prozess aufgrund unzureichenden adressierbaren Speichers nicht mehr funktioniert, kann eine Speicherverlustbedingung vorhanden sein.

Wenn der Computer, auf dem BizTalk Server ausgeführt wird, ein einzelnes Prozessorsystem ist, verwendet das .NET Framework die Workstation-Version des Ausführungsmoduls. Dies ist das Standardverhalten. Der Garbage Collector-Zuordnungsalgorithmus workstation ist nicht für die Skalierung oder den maximalen Durchsatz ausgelegt. 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. 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 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 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 Registrierungsschlüssel "String" mit den entsprechenden Werten:

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

BizTalk 2004

Erstellen Sie den folgenden CRL Host Registrierungsschlüssel "String" 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.

Nachfolgend sind häufige Ursachen und Lösungen aufgeführt:

Drosselungsschwellenwerte für prozess- und physische Arbeitsspeichernutzung

Die Schwellenwerte für die Drosselung des Prozessspeichers und der physischen Speicherauslastung können in BizTalk Server 2006 und in späteren Versionen geändert werden.

Standardmäßig ist der Schwellenwert für die Drosselung der Prozessspeicherauslastung auf 25 festgelegt. Wenn dieser Wert überschritten wird und der BizTalk-Prozessspeicher mehr als 300 MB beträgt, kann eine Einschränkungsbedingung auftreten. Auf einem 32-Bit-Server können Sie den Nutzungswert des Prozessspeichers auf 50 erhöhen. Auf einem 64-Bit-Server können Sie diesen Wert auf 100 erhöhen. Dies ermöglicht eine größere Speicherauslastung durch den BizTalk-Prozess, bevor eine Drosselung erfolgt.
Der Schwellenwert für die Drosselung der physischen Speicherauslastung hat den Standardwert 0. Dieser Schwellenwert misst den gesamten Systemspeicher. Wenn also ein anderer Wert als 0 konfiguriert ist, kann eine Einschränkungsbedingung auftreten, wenn ein Nicht-BizTalk-Prozess hohen Arbeitsspeicher verwendet.

Drosselungsschwellenwerte für Die Ausschalung

Die standardmäßigen Schwellenwerte für Speicherdedimensionierung können zu einer zu großen Dedimensionierung führen, wenn Orchestrierungen auf einem 64-Bit-Host ausgeführt werden. Weitere Informationen zu diesem Problem finden Sie unter "Dehydration Default Properties".

Hinweis

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

Auf einer äquivalenten Hardware in einer 32-Bit-Hostinstanz ist die beobachtete Dedimensionierung nominell, wenn die gleichen Orchestrierungen mithilfe der standardmäßigen Schwellenwerte für die Speicherentgrenzung ausgeführt werden.

Da die 64-Bit-Architektur erweiterten Speicheradressraum (16 TB anstelle von 4 GB) bereitstellt, wird 64-Bit-Hostinstanzen mehr Arbeitsspeicher als 32-Bit-Hostinstanzen zugewiesen. 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 Leistungsindikatoren \Process\Virtual Bytes und \Process\Private Bytes Performance Monitor, um die größte Speichermenge zu ermitteln, die von einer Orchestrierungsinstanz 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 value + 10%
Festlegen von MaximalUsage für beide Eigenschaften auf den OptimalUsage-Wert + 30 %

Beispiel: Wenn der Zählerwert des \Process\Virtual Byte Performance Monitor für eine Orchestrierungsinstanz 5.784.787.695 Bytes (5.517 MB) ist, legen Sie den OptimalUsage-Wert für VirtualMemoryThrottlingCrit fest. Bis 6.069 MB (5.784.787.695 * 1,10 = 6.363.266.464,5 Bytes).

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

Wenn der Leistungsmonitorwert von \Process\Private Bytes 435689400 Bytes (415 MB) ist, 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 werden die folgenden Werte in der datei BTSNTSvc64.exe.config angegeben, um die Drosselung zu reduzieren.

Leistungsüberwachungszähler	Zugewiesener Arbeitsspeicher	OptimalUsage	MaximalUsage
\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, welche Hostinstanz die Orchestrierung ausführt, können Sie den ID-Prozess aus den Leistungsindikatoren "\BizTalk: Messaging\ID Process" und "\Process\ID Process Performance Monitor" abgleichen. Überprüfen Sie dann den durchschnittlichen Wert, der für die entsprechenden Leistungsindikatoren "\Process\Virtual Bytes" und "\Process\Private Bytes Performance Monitor" angezeigt wird.

Hinweis

Informationen, die der Benutzer bemerken sollte, auch wenn "skimmingThe high dehydration" eine erhebliche Leistungsbeeinträchtigung verursachen kann, 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 enthalten die neuesten Fixes. Dazu gehören solche, die bekannte Probleme betreffen System.OutOfMemoryException .

Heapdecommitfreeblockthreshold

Standardmäßig ist der HeapDeCommitFreeBlockThreshold Registrierungsschlüsselwert 0. Der Wert 0 bedeutet, dass der Heap-Manager den Commit für jede 4 KB-Seite aufweist, 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 ist systemweit. Daher verwenden die meisten Prozesse beim Start mehr Arbeitsspeicher.
Berücksichtigen Sie diese Änderung nur für Systeme, die BizTalk Server als primäre Mission 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 Startwert.)
Standardwert: nicht vorhanden

Transformationsvorgänge

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

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

Verringern Sie die Anzahl der Nachrichten, die gleichzeitig verarbeitet BizTalk Server.
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 belegen. 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 tatsächlich aufrufenden Assembly. In dieser Situation wird ein gerootetes Objekt erstellt, das erst gelöscht wird, wenn der BizTalk-Dienst neu gestartet wird.

Der Großteil der BizTalk-Standardversion functoids wird als Inlineskript implementiert. Diese Elemente können dazu führen, dass System.Byte[] Objekte im Arbeitsspeicher gesammelt werden. Um den Speicherverbrauch zu minimieren, empfehlen wir, alle Zuordnungen, die diese functoids verwenden, in einer kleinen Assembly zu platzieren. Verweisen Sie dann auf diese Assembly. Verwenden Sie das folgende Diagramm, um zu bestimmen, welche functoids Inlineskripts und welche functoids keine Inlineskripts verwenden.

In der zweiten Spalte bedeutet "Ja ", dass dies functoid als Inlineskript implementiert wird und objekte im Arbeitsspeicher gesammelt werden System.Byte[] . Nein , dies functoid ist nicht als Inlineskript implementiert und bewirkt System.Byte[] nicht, dass Objekte im Arbeitsspeicher gesammelt werden.

Funktoide	Inlineskript?
Alle Zeichenfolgen-Functoids	Ja
Alle mathematischen Functoids	Ja
Alle logischen Functoids außer IsNil	Ja
Logisches IsNil-Functoid	Nein
Alle Datums-/Uhrzeit-Functoids	Ja
Alle Umwandlungs-Functoids	Ja
Alle wissenschaftlichen Functoids	Ja
Alle kumulierten Functoids	Ja
Alle Datenbank-Functoids	Nein

Erweiterte Functoids	Inlineskript?
Looping Functoid	Nein
Value-Mapping-Flattering Functoid	Nein
Assert Functoid	Nein
Table Extractor Functoid	Nein
Table Looping Functoid	Nein
Scripting Functoid mit Inline C #	Ja
Scripting Functoid with Inline JScript.NET	Ja
Scripting Functoid with Inline Visual Basic .NET	Ja
Scripting Functoid mit Inline XSLT	Nein
Scripting Functoid mit Inline-XSLT-Anrufvorlage	Nein
Scripting Functoid calling External Assembly	Nein
Nil Value Functoid	Nein
Wertzuordnungs-Functoid	Nein
Massenkopie-Functoid	Nein
Iterations-Functoid	Nein
Index Functoid	Nein
Record Count Functoid	Nein

BizTalk Server 2006 und neuere Versionen haben die Speicherverwaltung für große Dokumente erheblich verbessert. Zu diesem Zweck implementiert BizTalk Server einen konfigurierbaren Schwellenwert für die Nachrichtengröße zum Laden von Dokumenten in den Arbeitsspeicher während Transformationsvorgängen. Der Schwellenwert für die Standardnachrichtengröß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 nicht so viel Arbeitsspeicher während des Streamings. Benutzerdefinierte Pipelinekomponenten unterstützen jedoch möglicherweise kein Streaming.

Streaming unter starkem Stress

Send hosts run out of memory when they operate under heavy stress. BizTalk Server sendet Pipelines und sendet Adapter, die Streaming unterstützen. Beim Streaming lädt jede Komponente ein kleines Fragment des Datenstroms in den Speicher. Da jede Nachricht andere Datenstrukturen enthält, zusammen mit einem Nachrichtenkontext, der signifikant oder klein sein kann, wirkt sich dieses Verhalten auf das Verhalten von BizTalk Server unter starkem Stress aus.

Das Verhalten von BizTalk Server wird beeinflusst, 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 "LowDownMark " und im Feld "HighDownMark" der Adm_serviceClass Tabelle angezeigt werden. Die Adm_serviceClass Tabelle befindet sich in der BizTalk-Verwaltungsdatenbank. Diese Werte steuern die Anzahl der Nachrichten, die gleichzeitig verarbeitet oder gesendet BizTalk Server.

Der HighLimitMark-Wert ist die Gesamtzahl der Nachrichten, die das Modul gleichzeitig verarbeitet. Der Standardwert ist 200 Nachrichten pro CPU. Daher versucht der Sendehost auf einem 8-Prozessorserver, 1.600 Nachrichten (200 x 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 Wert "High Auswertmark" und den Wert " Low CsvMark " 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 erkannt 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. 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. Wenn ihr BizTalk Server Prozess eine Nicht-Arbeitsspeicher-Bedingung aufweist, wissen Sie daher, welche Komponenten beteiligt sind.

Schritte zur Problembehandlung

Verwenden Sie das Debugdiagnosetool, um probleme mit einem Zustand außerhalb des Arbeitsspeichers zu beheben, um Speicherzuweisungen im Laufe der Zeit zu überwachen. Das Tool "Debugdiagnose" kann eine Speicherverlustabbilddatei (DMP) erstellen und analysieren. Wenn Sie Speicherverluste beheben, besteht das Ziel darin, Leaktrack.dll anzufügen, bevor sich die hohe Speicherbedingung reproduzieren lässt, um das Speicherplus im Laufe der Zeit zu erfassen. Leaktrack.dll ist im Debugdiagnosetool enthalten.

Installieren Sie das Debugdiagnosetool.

Die folgende Datei steht im Microsoft Download Center zum Download zur Verfügung:
Herunterladen des Pakets für das Debugdiagnosetool

Weitere Informationen zum Herunterladen von Microsoft-Supportdateien finden Sie unter So erhalten Sie Microsoft-Supportdateien von Onlinediensten.

Microsoft hat diese Datei auf Viren überprüft. Microsoft hat die neueste Virenerkennungssoftware verwendet, die am Datum der Veröffentlichung der Datei verfügbar war. Die Datei wird auf Servern mit erweiterter Sicherheit gespeichert, die dazu beitragen, nicht autorisierte Änderungen an der Datei zu verhindern.
Verwenden Sie den Leistungsmonitor, um Daten über die 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 die Protokollierung der Leistungsüberwachung, bevor der Speicherverlust auftritt.

So verwenden Sie die Protokollierung des Leistungsmonitors

In den folgenden Abschnitten wird die Verwendung der Protokollierung der Leistungsüberwachung beschrieben.

Auswählen der zu protokollierenden Daten

Verwenden Sie die für Ihr Betriebssystem geeignete Methode, um die zu protokollierenden Daten auszuwählen:

Für Windows Server 2008 und Windows Server 2008 R2
1. Öffnen Sie in Verwaltungstools die Zuverlässigkeits- und Leistungsüberwachung.
2. Klicken Sie mit der rechten Maustaste auf "Leistungsüberwachung", klicken Sie auf "Neu " und dann auf " Datensammlungssatz".
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 Datensammlungssatz starten", und klicken Sie dann auf "Fertig stellen".
6. Erweitern Sie "Datensammlungssätze", " 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 Exceptions
  - .Net CLR Memory
  - 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 für den Wert des Beispielintervalls in 5 Sekunden.
  
  Hinweis
  
  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 benötigten Informationen abrufen können, ohne den Server zu überfordern.
11. Klicken Sie auf OK.

Klicken Sie im Menü "Aktion" auf "Beenden", um die Datensammlung zu beenden.

Für Windows Server 2003 oder für Windows XP
1. Erweitern Sie Leistungsprotokolle und Warnungen.
2. Klicken Sie mit der rechten Maustaste auf "Zählerprotokolle", und klicken Sie dann auf "Neues Protokoll Einstellungen". Das Dialogfeld Neues Protokoll Einstellungen 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 "Leistungsindikatoren hinzufügen".
6. Wählen Sie "Alle Indikatoren " und "Alle Instanzen" aus.
7. Wählen Sie in der Liste der Performance-Objekte die folgenden Objekte aus. Klicken Sie auf "Hinzufügen ", nachdem Sie die einzelnen Objekte ausgewählt haben.
  - .Net CLR Exceptions
  - .Net CLR Memory
  - 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 Datensamplingintervall in 5 Sekunden.
  
  Hinweis
  
  Der Wert des Datensampling-Intervalls 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 benötigten Informationen abrufen können, ohne den Server zu überfordern.
10. Klicken Sie auf OK. Klicken Sie zum Beenden der Datensammlung mit der rechten Maustaste auf den Namen des Zählerprotokolls, und klicken Sie dann auf "Beenden".

Abrufen der Abbilddatei

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

Methode 1: Automatisch

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

Starten Sie das Debugdiagnosetool 1.1.
Wählen Sie "Speicher" und "Handle Leak" aus, und klicken Sie dann auf "Weiter".
Wählen Sie den Btsntsvc.exe Prozess aus, und klicken Sie dann auf "Weiter".
Führen Sie auf der Seite "Leckregel konfigurieren " die folgenden Schritte aus:
1. Klicken Sie hier, um das Kontrollkästchen " Speicherverfolgung sofort starten" zu aktivieren, 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 die folgenden Schritte aus:
  - Vergewissern Sie sich, dass die Option zum automatischen 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 hier, um das Kontrollkästchen " Benutzerabbild generieren" zu aktivieren, wenn virtuelle Bytes das Kontrollkästchen erreichen , und behalten Sie den Standardwert 1024 bei.
  - Klicken Sie, um das und jedes zusätzliche Kontrollkästchen zu aktivieren und den Standardwert 200 beizubehalten. Durch Auswählen der Option zum Erreichen virtueller Bytes wird automatisch ein Speicherabbild erstellt, wenn virtuelle Bytes 1024 MB verwenden. Wenn virtuelle Bytes um 200 MB erhöht werden, 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 "Speicherort des Benutzers" auf dieser Seite ändern.
6. Klicken Sie auf Fertig stellen , um die Regel jetzt zu aktivieren.
  
  Hinweis
  
  Der Regelstatus lautet jetzt Nachverfolgung. Every time that a memory dump is created, the value will increase in the Userdump Count column on the Rules tab. The default memory dump location is C:\Program Files\DebugDiag\Logs.

Methode 2: Manuell

Sie können auch manuell Leaktrack.dll anhängen und die Speicherabbilddatei manuell abrufen. Auf diese Weise können Sie steuern, wann das Speicherabbild erstellt wird. Gehen Sie dazu wie folgt vor:

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

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

Starten Sie das Debugdiagnosetool 1.1.
Wählen Sie "Absturz" aus, und klicken Sie dann auf "Weiter".
Wählen Sie einen bestimmten Prozess aus, und klicken Sie dann auf "Weiter".
Wählen Sie den gleichen Btsntsvc.exe Prozess aus, und klicken Sie dann auf "Weiter".
Klicken Sie auf der Seite "Erweiterte Konfiguration (optional)" auf "Weiter".
Klicken Sie im Dialogfeld Speicherabbildspeicherort und Regelname auswählen (optional) auf "Weiter".
Wählen Sie jetzt "Regel aktivieren" aus, und klicken Sie dann auf "Fertig stellen".

Wenn der Prozess 60 bis 80 Prozent des ARBEITSSPEICHERs erreicht, klicken Sie mit der rechten Maustaste auf den Btsntsvc.exe Prozess, und klicken Sie dann auf "Vollständiges 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 Protokollierung des Leistungsmonitors

Wenn Sie ein Speicherabbild und Leistungsüberwachungsdaten erfassen, beenden Sie die Protokollierung des Leistungsmonitors etwa zwei Minuten, nachdem das Speicherabbild erstellt wurde.

Analysieren der Speicherabbilddatei

Um die Ursache für einen Speicherverlust zu ermitteln, können Sie das Debugdiagnosetool verwenden, um die Speicherabbilddatei zu analysieren. Gehen Sie dazu wie folgt vor:

Klicken Sie auf die Registerkarte "Erweiterte Analyse ".
Klicken Sie auf "Datendateien hinzufügen", und suchen Sie dann nach der DMP-Datei.
Wählen Sie das Skript "Speicherdruckanalyse " 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:

Öffnen Sie das Tool "Debugdiagnose".
Klicken Sie im Menü "Extras" auf "Optionen" und Einstellungen.
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 des Kundensupportdiensts und Informationen zu Supportkosten finden Sie unter "Support kontaktieren".

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