Generieren von Berichten und Diagrammen mit Leistungsindikatoren mit dem PAL-Tool (Performance Analysis of Logs) für BizTalk Server

Das PAL-Tool (Leistungsanalyse von Protokollen) liest ein Leistungsindikatorprotokoll für die Leistungsüberwachung (ein beliebiges bekanntes Format) und analysiert es mithilfe komplexer, aber bekannter Schwellenwerte (bereitgestellt). Das Tool generiert einen HTML-basierten Bericht, der wichtige Leistungsindikatoren grafisch darstellt und Warnungen auslöst, wenn Schwellenwerte überschritten werden. Die Schwellenwerte basieren ursprünglich auf Schwellenwerten, die von den Microsoft-Produktteams definiert wurden, einschließlich BizTalk Server und Mitgliedern des Microsoft-Supports. Dieses Tool ersetzt nicht die herkömmliche Leistungsanalyse, sondern automatisiert die Analyse von Leistungsindikatorprotokollen ausreichend, um Zeit zu sparen. Das PAL-Tool:

• Analysiert Leistungsindikatorprotokolle auf Schwellenwerte

• Ist hilfreich für große Perfmon-Protokolle

• Identifiziert BizTalk Server- und Betriebssystemleistungsindikatorengpässe durch Die Analyse auf Schwellenwerte

• Ist erweiterbar, um Analysen für alle Leistungsindikatoren durchzuführen.

• Kann verwendet werden, um einen eigenen Leistungsindikator zu schreiben.

  PAL steht als kostenloser Download auf GitHub zur Verfügung. Hierfür ist Microsoft Log Parser erforderlich. Log Parser ist ein leistungsstarkes, vielseitiges Tool, das universellen Abfragezugriff auf textbasierte Daten wie Protokolldateien, XML-Dateien und CSV-Dateien sowie wichtige Datenquellen des Windows-Betriebssystems wie das Ereignisprotokoll, die Registrierung, das Dateisystem und den Active Directory-Verzeichnisdienst® bietet. Sie können dieses Tool verwenden, um eine beträchtliche Menge an Protokollierungsinformationen abzufragen. Sie können das Protokollparser-Tool herunterladen.

Verwenden von PAL mit Leistungsindikatorprotokollen in verschiedenen Sprachen

Das PAL-Tool analysiert Leistungsindikatorprotokolle nur in englischer Sprache. Um das PAL-Tool mit Leistungsindikatorprotokollen in anderen Sprachen zu verwenden, müssen Sie die Protokolle zunächst in englischer Sprache übersetzen. Sie können den Perfmon-Protokollübersetzung verwenden, um die ursprünglichen Leistungsindikatorprotokolldateien ins Englische zu übersetzen.

Grundlegendes zum PAL-Toolbericht für Microsoft BizTalk Server 2010

Das PAL-Tool bietet perfmon-Protokollanalyse von Schwellenwerten für das Windows-Betriebssystem, microsoft SQL Server und BizTalk Server. In diesem Abschnitt werden die meisten Analysen im BizTalk Server Schwellenwertbericht im PAL-Tool beschrieben.

Hinweis

Dieses Thema ist lang, sodass umfassende Informationen über das PAL-Tool an einem Ort zur einfachen Referenz enthalten werden können.

Die folgenden Analysen und Schwellenwerte werden vom PAL-Tool gemeldet.

Analysetyp und -name	Beschreibung der Analyse
Datenträger: Freier Speicherplatz für ein Kernelabbild	Bei dieser Analyse wird überprüft, ob genügend freier Speicherplatz für das Betriebssystem vorhanden ist, um den gesamten Arbeitsspeicher auf dem Datenträger abzuspeichern. Wenn nicht genügend Speicherplatz verfügbar ist, kann das Betriebssystem keine datei memory.dmp erstellen, die erforderlich ist, um die Grundursache eines Kernelabbilds zu analysieren.
Datenträger: Logische/Physische Datenträgerschnittstellenanalyse	Bei dieser Analyse wird die Leerlaufzeit der einzelnen physischen Datenträger untersucht. Je mehr im Leerlauf der Datenträger ist, desto weniger wird der Datenträger verwendet. Dieser Indikator wird am besten verwendet, wenn ein Datenträger auf dem logischen Datenträger verwendet wird. "% Leerlaufzeit" gibt den Prozentsatz der Zeit während des Beispielintervalls an, in dem sich der Datenträger im Leerlauf befand. Referenz: Ausschließen von Disk-Bound Problemen
Datenträger: Analyse der Lese-/Schreiblatenz auf logischem/physischem Datenträger	Die zuverlässigste Möglichkeit für Windows, einen Datenträgerleistungsengpass zu erkennen, besteht darin, die Antwortzeiten zu messen. Wenn die Antwortzeiten größer als 0,025 (25 Millisekunden) sind, was ein konservativer Schwellenwert ist, können spürbare Verlangsamungen und Leistungsprobleme auftreten, die sich auf Benutzer auswirken. Weitere Informationen finden Sie in diesem Thema unter Analyse der Lese-/Schreiblatenz logischer/physischer Datenträger.
Datenträger: Logische Datenträgerübertragungen/s	"Datenträgerübertragungen/s" ist die Rate von Lese- und Schreibvorgängen auf dem Datenträger. Die Schwellenwerte für diese Analyse überprüfen, ob einer der logischen Datenträger schlechte Antwortzeiten (mehr als 25 ms Antwortzeiten für E/A-Vorgänge) anzeigt. Wenn dies zutrifft, sollten die Datenträgerübertragungen pro Sekunde bei oder über 80 liegen. Andernfalls muss die Datenträgerarchitektur untersucht werden. Die häufigste Ursache für schlechte Datenträger-E/A ist die LUN-Überladung auf dem SAN. Weitere Informationen finden Sie unter Logische Datenträgerübertragungen/Sekunde in diesem Thema.
Datenträger: Logischer Datenträger in % freier Speicherplatz	"% Freier Speicherplatz" ist der Prozentsatz des gesamten nutzbaren Speicherplatzes, der auf dem ausgewählten logischen Laufwerk frei war. Die Leistung sollte erst beeinträchtigt werden, wenn der verfügbare Speicherplatz auf dem Datenträger kleiner als 30 Prozent ist. Wenn 70 Prozent des Datenträgers verwendet werden, befindet sich der verbleibende freie Speicherplatz näher an der Spindel des Datenträgers in der Mitte des Laufwerks, das auf einer niedrigeren Leistungsebene arbeitet. Ein Mangel an freiem Speicherplatz kann zu einer schwerwiegenden Datenträgerleistung führen.
Datenträger: Verarbeiten von E/A-Datenvorgängen/Sekunde und Prozess-E/A Sonstige Vorgänge/s-Analyse	Diese Leistungsindikatoren zählen alle E/A-Aktivitäten, die vom Prozess generiert werden, um Datei-, Netzwerk- und Geräte-E/A-Vorgänge einzuschließen. Diese Analysen überprüfen, wann Prozesse mehr als 1.000 E/A-Vorgänge pro Sekunde ausführen, und kennzeichnen sie als Warnung. Diese Analysen werden am besten in Korrelation mit anderen Analysen wie der Datenträgeranalyse verwendet, um zu bestimmen, welche Prozesse an der E/A-Aktivität beteiligt sein könnten.
Arbeitsspeicher: Verfügbarer Arbeitsspeicher	Bei dieser Analyse wird überprüft, ob der gesamte verfügbare Arbeitsspeicher gering ist– Warnung bei 10 Prozent verfügbar und Kritisch bei 5 Prozent verfügbar. Eine Warnung wird auch ausgegeben, wenn ein abnehmender Trend von 10 MB pro Stunde erkannt wird, was auf eine potenzielle bevorstehende Arbeitsspeicherbedingung hindeuten kann. Ein geringer physischer Arbeitsspeicher kann zu erhöhten CPU- und Systemverzögerungen im privilegierten Modus führen. Weitere Informationen finden Sie unter Verfügbarer ArbeitsspeicherAnalyse in diesem Thema.
Arbeitsspeicher: Freie Systemseitentabelleneinträge	Free System Page Table Entries (PTE's) sind die Anzahl der Seitentabelleneinträge, die derzeit nicht vom System verwendet werden. Diese Analyse bestimmt, ob dem System die PTE-Anzahl ausgeht, indem überprüft wird, ob weniger als 5.000 kostenlose PTE's mit einer Warnung vorhanden sind, wenn weniger als 10.000 kostenlose PTE-Dateien vorhanden sind. Mangel an ausreichend PTE's kann zu systemweiten Hängen führen. Beachten Sie auch, dass der Schalter /3GB die Menge der freien PTE erheblich verringert. Weitere Informationen finden Sie unter Free System Page Table Entries Analysis in diesem Thema.
Arbeitsspeicher: Erkennung von Speicherverlusten	Bei dieser Analyse wird ermittelt, ob einer der Prozesse einen großen Teil des Systemspeichers verbraucht und ob der Speicherverbrauch im Laufe der Zeit zunimmt. Ein Prozess, der große Teile des Arbeitsspeichers verbraucht, ist in Ordnung, solange der Prozess den Arbeitsspeicher an das System zurückgibt. Suchen Sie im Diagramm nach steigenden Trends. Ein zunehmender Trend über einen längeren Zeitraum kann auf einen Speicherverlust hinweisen. "Private Bytes" ist die aktuelle Größe des Arbeitsspeichers in Bytes, den dieser Prozess zugewiesen hat und der nicht für andere Prozesse freigegeben werden kann. Bei dieser Analyse wird überprüft, ob 10 MB pro Stunde und 5 MB pro Stunde trends steigen. Verwenden Sie diese Analyse in Korrelation mit der Analyse des verfügbaren Arbeitsspeichers in PAL. Weitere Informationen finden Sie unter Analyse der Speicherleckerkennung in diesem Thema.
Arbeitsspeicher: Behandeln der Leckerkennung	Diese Analyse überprüft alle Prozesse, um zu bestimmen, wie viele Handles jeweils geöffnet sind, und um zu ermitteln, ob ein Handle-Leak vermutet wird. Ein Prozess mit einer großen Anzahl von Handles und/oder einem aggressiven Aufwärtstrend kann auf einen Handle-Leak hinweisen, was in der Regel zu einem Speicherverlust führt. Die Gesamtzahl der Handles, die derzeit von diesem Prozess geöffnet werden, entspricht der Summe der Handles, die derzeit von jedem Thread in diesem Prozess geöffnet werden. Referenz: Debugdiagnosetool
Arbeitsspeicher: Eingabe von Speicherseiten/Sekunde	"Seiteneingabe/Sekunde" ist die Rate, mit der Seiten vom Datenträger gelesen werden, um HardPage-Fehler zu beheben. Schwerwiegende Seitenfehler treten auf, wenn ein Prozess auf eine Seite im virtuellen Speicher verweist, die sich nicht seinem Arbeitssatz oder an einer anderen Stelle im physischen Speicher befindet und vom Datenträger abgerufen werden muss. Bei dieser Analyse wird überprüft, ob mehr als 10 Seitendateilesungen pro Sekunde vorliegen.
Arbeitsspeicher: Speicherseiten/Sekunde	Bei dieser Analyse wird überprüft, ob die "Seiten/Sekunde" hoch ist (über 1.000). Wenn es hoch ist, ist dem System wahrscheinlich der Arbeitsspeicher nicht mehr verfügbar, indem versucht wird, den Arbeitsspeicher auf den Datenträger auszugeben. "Seiten/Sekunde" ist die Rate, mit der Seiten aus dem Datenträger gelesen oder auf den Datenträger geschrieben werden, um fehlerbehaftete Seiten zu beheben. Dieser Indikator ist ein primärer Indikator für die Arten von Fehlern, die systemweite Verzögerungen verursachen. Verwenden Sie diese Analyse in Korrelation mit der Analyse des verfügbaren Arbeitsspeichers und der Analyse der Speicherleckerkennung in PAL. Wenn alle diese Analysen gleichzeitig Warnungen auslösen, kann dies darauf hindeuten, dass dem System der Arbeitsspeicher und die beteiligten verdächtigen Prozesse ausgehen und die Analyseschritte befolgen, die in der Analyse zur Erkennung von Speicherlecks in PAL beschrieben sind. Weitere Informationen finden Sie unter Speicherseiten/s Analyse in diesem Thema.
Arbeitsspeicher: Speichersystemcache-residente Bytes	"Systemcache Resident Bytes" ist die Größe des auslagerungsfähigen Betriebssystemcodes im Dateisystemcache in Bytes. Dieser Wert umfasst nur aktuelle physische Seiten, nicht aber virtuelle Speicherseiten, die gegenwärtig nicht resident sind. Dieser Wert ist eine Komponente von "Memory\\System Code Resident Bytes", die den gesamten auslagerungsfähigen Betriebssystemcode darstellt, der sich derzeit im physischen Arbeitsspeicher befindet. Dieser Indikator zeigt nur den zuletzt ermittelten Wert an, keinen Durchschnittswert. Bei dieser Analyse wird ein steigender Trend von 10 MB pro Stunde überprüft. Unter Last kann ein Server den Systemcache verwenden, um E/A-Aktivitäten wie Datenträger zwischenzuspeichern. Verwenden Sie in Korrelation mit Prozess-E/s-Datenvorgängen/Sek. und Prozess-E/A Andere Vorgänge/Sek. Analysen in PAL. Referenz: Leistung und Optimierung des Dateicaches
Arbeitsspeicher: Pool von nicht ausgelagerten Bytes	"Nicht ausgelagerte Poolbytes" ist die Größe des nicht ausgelagerten Pools, ein Bereich des Systemspeichers für Objekte, die nicht auf den Datenträger geschrieben werden können, aber im physischen Arbeitsspeicher verbleiben müssen, solange sie zugeordnet sind. Bei dieser Analyse wird überprüft, ob das System der maximalen Nicht-Auslagerungsspeichergröße des Pools nahe kommt. Dazu werden die Poolgrößen unter Berücksichtigung von /3 GB, physischer Arbeitsspeichergröße und 32-Bit/64-Bit geschätzt, um dann zu ermitteln, ob der Wert höher als 60 Prozent der geschätzten Poolgröße ist. Wenn das System der maximalen Größe nahe kommt, kann es zu systemweiten Hängern führen. Die Option /3GB in der boot.ini-Datei reduziert die Größe dieses Speicherpools erheblich. Weitere Informationen finden Sie in diesem Thema unter Poolanalyse von nicht ausgelagerten Bytes.
Arbeitsspeicher: Ausgelagerte Bytes im Pool	Bei dieser Analyse wird überprüft, ob das System der maximalen Auslagerungsspeichergröße des Pools nahe kommt. Dazu werden die Poolgrößen unter Berücksichtigung von /3 GB, physischer Arbeitsspeichergröße und 32-Bit/64-Bit geschätzt, um dann zu ermitteln, ob der Wert höher als 60 Prozent der geschätzten Poolgröße ist. Wenn das System der maximalen Größe nahe kommt, kann es zu systemweiten Hängern führen. Die Option /3GB in der boot.ini-Datei reduziert die Größe dieses Speicherpools erheblich. Weitere Informationen finden Sie in diesem Thema unter Pool-Analyse von ausgelagerten Bytes.
Arbeitsspeicher: Anzahl des Prozessthreads	Bei dieser Analyse werden alle Prozesse überprüft, um festzustellen, ob ein Prozess über mehr als 500 Threads verfügt und ob die Anzahl der Threads um 50 Threads pro Stunde zunimmt. Ein Prozess mit einer großen Anzahl von Threads und/oder einem aggressiven Aufwärtstrend kann auf einen Threadverlust hinweisen, der in der Regel zu einem Speicherverlust oder einem hohen Kontextwechsel führt. Ein hoher Kontextwechsel führt zu einer CPU mit hohem Privilegierten Modus.
Arbeitsspeicher: Prozessarbeitssatz	"Working Set" ist die aktuelle Größe des Arbeitssatzes dieses Prozesses in Bytes. Der Arbeitssatz ist der Satz von Speicherseiten, die kürzlich von den Threads im Prozess berührt wurden. Wenn der freie Arbeitsspeicher auf dem Computer über einem Schwellenwert liegt, verbleiben Seiten im Arbeitssatz eines Prozesses, auch wenn sie nicht verwendet werden. Wenn freier Arbeitsspeicher unter einen Schwellenwert fällt, werden Seiten auf Arbeitssätze gekürzt. Wenn sie benötigt werden, werden sie vorläufig wieder in den Arbeitssatz eingegliedert, bevor sie Standard Arbeitsspeicher verlassen. Bei dieser Analyse wird auf einen steigenden Trend von 10 MB oder mehr in jedem der Prozesse überprüft. Verwenden Sie in Korrelation mit der Analyse des verfügbaren Arbeitsspeichers in PAL. Referenz: Ermitteln und Beseitigen von Engpässen
Netzwerk: Analyse der Warteschlangenlänge der Netzwerkausgabe	Bei dieser Analyse wird überprüft, wie viele Threads auf den Netzwerkadapter warten. Wenn viele Threads auf den Netzwerkadapter warten, wird die Netzwerk-E/A-Netzwerk-E/A wahrscheinlich aufgrund von Netzwerklatenz oder Netzwerkbandbreite überlastt. "Länge der Ausgabewarteschlange" ist die Länge der Ausgabepaketwarteschlange (in Paketen). Verzögerungen werden angezeigt, wenn dies länger als zwei ist, und der Engpass sollte nach Möglichkeit gefunden und beseitigt werden. Typische Ursachen für Netzwerkausgabewarteschlangen sind eine hohe Anzahl kleiner Netzwerkanforderungen und Netzwerklatenz.
Netzwerk: Analyse der Netzwerkauslastung	"Bytes Total/sec" ist die Rate, mit der Bytes über jeden Netzwerkadapter gesendet und empfangen werden, einschließlich Rahmenzeichen. "Netzwerkschnittstelle\Empfangene Bytes/sec" ist eine Summe aus "Netzwerkschnittstelle\Empfangene Bytes/Sec" und "Netzwerkschnittstelle\Gesendete Bytes/Sek.". Dieser Indikator hilft Ihnen zu ermitteln, ob der Datenverkehr an Ihrem Netzwerkadapter überlastet ist und ob Sie einen weiteren Netzwerkadapter hinzufügen müssen. Wie schnell Sie ein Problem identifizieren können, hängt von der Art des Netzwerks ab, über das Sie verfügen, und davon, ob Sie die Bandbreite für andere Anwendungen gemeinsam nutzen. Diese Analyse konvertiert "Bytes Total/Sec" in Bits und vergleicht sie mit der aktuellen Bandbreite des Netzwerkadapters, um die Netzwerknutzung zu berechnen. Als Nächstes wird überprüft, ob die Auslastung über 50 Prozent liegt. Referenz: Messen der Leistung mithilfe von EventCounters in .NET Core
Auslagerungsdatei: Auslagerungsdatei % Nutzung und % Auslastungsspitz	Die Menge der verwendeten Auslagerungsdatei instance in Prozent. Siehe auch "Prozess\\Page File Bytes". Bei dieser Analyse wird überprüft, ob der Prozentsatz der Nutzung größer als 70 Prozent ist.
Prozessor: Analyse der Prozessorauslastung und übermäßige Prozessornutzung durch Prozesse	Dieser Indikator ist der primäre Indikator für die Prozessoraktivität und zeigt den durchschnittlichen Prozentsatz der während des Stichprobenintervalls beobachteten Auslastungszeit an. Er wird berechnet, indem die Zeit überwacht wird, zu der der Dienst inaktiv ist, und dieser Wert von 100 Prozent subtrahiert wird. Bei dieser Analyse wird auf eine Auslastung von mehr als 60 Prozent für jeden Prozessor überprüft. Wenn ja, stellen Sie fest, ob es sich um cpu- oder hochprivilegiert-Modus handelt. Wenn die CPU mit hohem Privilegierten Modus vermutet wird, lesen Sie die CPU-Analyse des privilegierten Modus in PAL. Wenn ein Prozessorengpass im Benutzermodus vermutet wird, sollten Sie einen Prozessprofiler verwenden, um die Funktionen zu analysieren, die den hohen CPU-Verbrauch verursachen.
Prozessor: Prozessorwarteschlangenlänge	Diese Analyse bestimmt, ob die durchschnittliche Prozessorwarteschlangenlänge die Anzahl der Prozessoren überschreitet. Wenn dies der Fall ist, kann dies auf einen Prozessorengpass hinweisen. Verwenden Sie diese Analyse in Korrelation mit der CPU-Analyse im privilegierten Modus und der Analyse übermäßiger Prozessornutzung durch Prozess in PAL. Ausführliche Informationen finden Sie unter Analyse der Prozessorwarteschlangenlänge in diesem Thema.
Prozessor: CPU-Analyse im privilegierten Modus	Dieser Indikator gibt den Prozentsatz der Zeit an, die ein Thread im privilegierten Modus ausführt. Wenn Ihre Anwendung Betriebssystemfunktionen aufruft (z. B. zum Ausführen von Datei- oder Netzwerk-E/A oder zum Zuweisen von Arbeitsspeicher), werden diese Betriebssystemfunktionen im privilegierten Modus ausgeführt. Bei dieser Analyse wird überprüft, ob die CPU im privilegierten Modus mehr als 30 Prozent der gesamten CPU verbraucht. Wenn ja, wird der CPU-Verbrauch wahrscheinlich durch einen anderen Engpass als den Prozessor verursacht, z. B. Netzwerk-, Arbeitsspeicher- oder Datenträger-E/A. Verwenden Sie in Korrelation mit Prozessor: % Interruptzeit und Prozessor: Analysen mit hohem Kontextwechsel in PAL. Weitere Informationen finden Sie unter Cpu-Analyse im privilegierten Modus in diesem Thema.
Prozessor: Unterbrechungszeit	"% Interruptzeit" ist die Zeit, die der Prozessor damit verbringt, Hardwareunterbrechungen während der Beispielintervalle zu empfangen und zu warten. Dieser Wert ist ein indirekter Indikator für die Aktivität von Geräten, die Interrupts generieren, wie z. B. Systemuhr, Maus, Datenträgertreiber, Datenkommunikationsleitungen, Netzwerkschnittstellenkarten und andere Peripheriegeräte. Diese Geräte erzeugen normalerweise einen Prozessorinterrupt, wenn sie einen Vorgang abgeschlossen haben oder ein Eingreifen erfordern. Die normale Threadausführung wird während der Interrupts ausgesetzt. Die meisten Systemuhren unterbrechen den Prozessor alle 10 Millisekunden und führen damit im Hintergrund zu Interruptaktivität. Ein dramatischer Anstieg dieses Indikators deutet auf potenzielle Hardwareprobleme hin. Bei dieser Analyse wird überprüft, ob "% Interruptzeit" größer als 30 Prozent ist. In diesem Fall sollten Sie gerätetreiber für Hardware aktualisieren, die mit dieser Warnung korreliert. Referenz: Messen der Leistung mithilfe von EventCounters in .NET Core
Prozessor: Hoher Kontextwechsel	Ein Kontextwechsel erfolgt, wenn ein Thread mit höherer Priorität einem Thread mit niedrigerer Priorität, der derzeit ausgeführt wird, oder wenn ein Thread mit hoher Priorität blockiert wird. Ein hohes Maß an Kontextwechseln kann auftreten, wenn viele Threads dieselbe Prioritätsebene haben. Dies deutet häufig darauf hin, dass zu viele Threads um die Prozessoren im System konkurrieren. In der Regel sind Kontextwechselraten von weniger als 5.000 pro Sekunde und Prozessor keine Sorge wert. Wenn die Kontextwechselraten 15.000 pro Sekunde pro Prozessor überschreiten, besteht eine Einschränkung. Weitere Informationen finden Sie in diesem Thema unter Analyse mit hohem Kontextwechsel.
Microsof BizTalk Server: BizTalk Dehydrierungs orchestriert	Wenn viele lang andauernde Geschäftsprozesse gleichzeitig ausgeführt werden, sind Speicher- und Leistungsprobleme möglich. Um solche Probleme zu vermeiden, werden Orchestrierungsinstanzen von der Orchestrierungs-Engine "pausiert" und "reaktiviert". Pausieren ist ein Vorgang, bei dem der Status einer Orchestrierung in eine SQL Server-Datenbank serialisiert wird. Die Rehydration ist das Gegenteil dieses Prozesses: Deserialisieren deserialisieren deserialisieren des letzten Ausführungszustands einer Orchestrierung aus der Datenbank. Mit dem Pausieren soll die Inanspruchnahme von Systemressourcen minimiert werden, indem man die Anzahl der Orchestrierungen verringert, die gleichzeitig im Speicher instanziiert sein müssen. Daher sparen Enthyrationen den Arbeitsspeicherverbrauch, sind aber relativ teure Vorgänge. Bei dieser Analyse wird auf Dehydrierung von 10 oder mehr überprüft. Wenn ja, BizTalk Server möglicherweise der Arbeitsspeicher (entweder virtuell oder physisch) ausgeht, eine hohe Anzahl von Orchestrierungen auf Nachrichten wartet, oder die Dehydrierungseinstellungen werden nicht ordnungsgemäß festgelegt. Referenz: Orchestrierungshydrierung und Rehydrierung
Microsoft BizTalk Server: BizTalk High Database-Sitzungen	Dieser Indikator hat zwei mögliche Werte: normal (0) oder überschritten (1). Bei dieser Analyse wird der Wert 1 überprüft. Wenn ja, hat BizTalk den Schwellenwert der zulässigen Anzahl von Datenbanksitzungen überschritten. Dieser Wert wird durch den Wert "Datenbankverbindung pro CPU" in den BizTalk-Hostdrosselungseinstellungen gesteuert. "Datenbankverbindung pro CPU" ist die maximale Anzahl gleichzeitiger Datenbanksitzungen (pro CPU), die vor Beginn der Drosselung zulässig sind. Anhand des Leistungsindikators Datenbanksitzung unter der Leistungsobjektkategorie BizTalk:Nachrichtenagent können Sie die Anzahl der aktiven Datenbankverbindungen überwachen. Dieser Parameter wirkt sich nur auf die Einschränkung ausgehender Nachrichten aus. Weitere Informationen finden Sie unter BizTalk High Database Sessions Analysis in diesem Thema.
Microsoft BizTalk Server: BizTalk High Database Size	Dieser Indikator wird auf den Wert 1 festgelegt, wenn eine der Bedingungen für die Nachrichtenanzahl im Datenbankschwellenwert auftritt. Standardmäßig ist die Anzahl der Hostnachrichten in der Datenbankdrosselung auf einen Wert von 50.000 festgelegt, wodurch unter den folgenden Umständen eine Drosselungsbedingung ausgelöst wird: – Die Gesamtzahl der vom Host veröffentlichten Nachrichten instance den Arbeits-, Zustands- und angehaltenen Warteschlangen der abonnierenden Hosts übersteigt 50.000. – Die Anzahl der Nachrichten in der Spooltabelle oder der Nachverfolgungstabelle überschreitet 500.000 Nachrichten. In diesem Fall sollten Sie eine Vorgehensweise in Betracht ziehen, die die Anzahl der Nachrichten in der Datenbank reduziert. Stellen Sie beispielsweise sicher, dass die SQL Server Aufträge in BizTalk Server fehlerfrei ausgeführt werden, und verwenden Sie die Seite Group Hub in der BizTalk Server-Verwaltungskonsole, um zu ermitteln, ob die Meldungserstellung durch eine große Anzahl an angehaltenen Nachrichten verursacht wird. Weitere Informationen finden Sie unter BizTalk High Database Size Analysis in diesem Thema.
Microsoft BizTalk Server: BizTalk High In-Process Message Count	Bei dieser Analyse wird der Zähler "Hohe In-Process Nachrichtenanzahl" überprüft, um zu bestimmen, ob diese Art von Drosselung auftritt. Wenn ja, sollten Sie die Einstellung "In-Process messages per CPU" (In-Process-Nachrichten pro CPU) anpassen. Dieser Parameter wirkt sich nur auf die Einschränkung ausgehender Nachrichten aus. Geben Sie den Wert 0 in die Einstellung "In-Process messages per CPU" ein, um die Drosselung basierend auf der Anzahl der In-Process-Nachrichten pro CPU zu deaktivieren. Der Standardwert für die Einstellung "In-Process messages per CPU" ist 1.000. Beachten Sie, dass sich das Ändern dieses Werts auch auf die geringe Latenz von Nachrichten und/oder die Effizienz von BizTalk-Ressourcen auswirken kann. Weitere Informationen finden Sie unter BizTalk High In-Process Message Count Analysis in diesem Thema.
Microsoft BizTalk Server: BizTalk High Message Delivery Rate	Bei dieser Analyse wird der Wert 1 im Leistungsindikator "Hohe Nachrichtenübermittlungsrate" überprüft. Hohe Nachrichtenübermittlungsraten können durch eine hohe Verarbeitungskomplexität, langsame ausgehende Adapter oder einen vorübergehenden Mangel an Systemressourcen verursacht werden. Weitere Informationen finden Sie unter BizTalk High Message Delivery Rate Analysis in diesem Thema.
Microsoft BizTalk Server: BizTalk High Message Publishing Rate	Die eingehende Hosteinschränkung (in BizTalk Server auch als Einschränken der Nachrichtenveröffentlichung bezeichnet) wird auf Hostinstanzen angewendet, die Empfangsadapter oder Orchestrierungen enthalten, die Nachrichten in der MessageBox-Datenbank veröffentlichen. Bei dieser Analyse wird der Wert 1 im Leistungsindikator "Hohe Nachrichtenveröffentlichungsrate" überprüft. In diesem Fall kann die Datenbank nicht mit der Veröffentlichungsrate von Nachrichten in der BizTalk MessageBox-Datenbank Schritt halten. Referenzen: - Host Drosselungsleistungsindikatoren - Implementieren der Hostdrosselung BizTalk Server - Ändern der Einstellungen für die ratenbasierte Drosselung - Was ist host Drosselung?
Microsoft BizTalk Server: BizTalk High Process Memory	Die Einstellung bizTalk Process Memory usage drosselt den Prozentsatz des verwendeten Arbeitsspeichers im Vergleich zur Summe der Größe des Arbeitssatzes und des gesamten verfügbaren virtuellen Arbeitsspeichers für den Prozess, wenn ein Wert von 1 bis 100 eingegeben wird. Wenn Sie einen Prozentwert eingeben, wird der Schwellenwert für den Prozessspeicher in regelmäßigen Abständen neu berechnet. Bei dieser Analyse wird der Wert 1 im Leistungsindikator "Hoher Prozessarbeitsspeicher" überprüft. Weitere Informationen finden Sie unter BizTalk High Process Memory Analysis in diesem Thema.
Microsoft BizTalk Server: BizTalk High System Memory	Die Einstellung Drosselungsschwellenwert für die Verwendung des physischen Arbeitsspeichers von BizTalk ist der Prozentsatz des Arbeitsspeicherverbrauchs im Vergleich zur Gesamtmenge des verfügbaren physischen Arbeitsspeichers, wenn ein Wert von 1 bis 100 eingegeben wird. Diese Einstellung kann auch die Gesamtmenge des verfügbaren physischen Arbeitsspeichers in Megabyte sein, wenn ein Wert größer als 100 eingegeben wird. Geben Sie zum Deaktivieren der auf der Auslastung des physikalischen Speichers basierenden Einschränkung den Wert 0 ein. Der Standardwert ist 0. Weitere Informationen finden Sie unter BizTalk High System Memory Analysis in diesem Thema.
Microsoft BizTalk Server: Hohe Anzahl von BizTalk-Threads	"Threads pro CPU" ist die Gesamtanzahl der Threads im Hostprozess, einschließlich der von Adaptern verwendeten Threads. Wenn dieser Schwellenwert überschritten wird, versuchen BizTalk Server, die Größe des EPM-Threadpools und des Nachrichten-Agent-Threadpools zu verringern. In Szenarien, in denen eine hohe Last zum Erstellen einer großen Anzahl von Threads führen kann, sollte die threadbasierte Einschränkung aktiviert werden. Dieser Parameter wirkt sich auf die Einschränkung eingehender und ausgehender Nachrichten aus. Die threadbasierte Drosselung ist standardmäßig deaktiviert. Weitere Informationen finden Sie unter BizTalk High Thread Count Analysis in diesem Thema.
Microsoft BizTalk Server: Länge der BizTalk-Hostwarteschlange	Die BizTalk-Hostwarteschlangenlänge verfolgt die Gesamtzahl der Nachrichten in der jeweiligen Hostwarteschlange. Sie können die Längengröße verwenden, z. B. BizTalk:MessageBox:HostCounters:Host Queue – Length, um eine detailliertere Ansicht der Anzahl der Nachrichten zu erhalten, die intern in die Warteschlange eingereiht werden, indem Sie die Warteschlangentiefe für einen einzelnen Host anzeigen. Dieser Indikator kann hilfreich sein, um zu bestimmen, ob ein bestimmter Host eng ist. Wenn für jeden Transport eindeutige Hosts verwendet werden, kann dies hilfreich sein, um potenzielle Transportengpässe zu ermitteln. Bei dieser Analyse wird überprüft, ob die durchschnittliche Warteschlangenlänge größer als 1 ist. Die Länge der Hostwarteschlange ist eine gewichtete Warteschlangenlänge, indem die Datensatzanzahl aller Warteschlangen (Work Q, State Q, Suspended Q) des Zielhosts aggregiert wird. Referenz: BizTalk Server 2010: BizTalk Server Leistungstestmethodik
Microsoft BizTalk Server: Warteschlangenlänge für angehaltene BizTalk-Hostnachrichten	Mit diesem Leistungsindikator wird die Gesamtzahl der angehaltenen Nachrichten für den jeweiligen Host nachverfolgt. Eine angehaltene Nachricht ist ein instance einer Nachricht oder Orchestrierung, die BizTalk Server die Verarbeitung aufgrund eines Fehlers im System oder der Nachricht beendet hat. Instanzen, die aufgrund eines Systemfehlers angehalten wurden, können in der Regel nach Behebung des Systemproblems wieder aufgenommen werden. Instanzen, die aufgrund eines Nachrichtenfehlers angehalten wurden, können häufig nicht wieder aufgenommen werden. In diesem Fall muss die Nachricht selbst repariert und erneut an das BizTalk Server-System übermittelt werden. Die angehaltene Nachrichtenwarteschlange ist eine Warteschlange, die Arbeitselemente enthält, für die während der Verarbeitung ein Fehler oder Fehler aufgetreten ist. In der Warteschlange „Angehalten“ werden die Nachrichten gespeichert, bis sie korrigiert und erneut verarbeitet bzw. gelöscht werden können. Bei dieser Analyse wird überprüft, ob angehaltene Nachrichten vorkommen. Ein zunehmender Trend kann auf schwerwiegende Verarbeitungsfehler hinweisen. Referenzen: - Überwachen von Integrität und Leistung BizTalk Server - Problembehandlung bei Microsoft BizTalk Server
BizTalk Server: BizTalk-Orchestrierungen im Leerlauf	Die Anzahl der Orchestrierungsinstanzen im Leerlauf, die derzeit von der Hostinstanz gehostet werden. Dieser Indikator bezieht sich auf Orchestrierungen, die keinen Fortschritt machen, aber nicht dehydrierbar sind. Diese Situation kann auftreten, wenn die Orchestrierung blockiert wird und auf einen Empfang, ein Lauschen oder eine Verzögerung in einer atomischen Transaktion wartet. Wenn sich eine große Anzahl nicht dehydrierbarer Orchestrierungen ansammelt, ist bizTalk möglicherweise nicht genügend Arbeitsspeicher vorhanden. Pausieren ist ein Vorgang, bei dem der Status einer Orchestrierung in eine SQL Server-Datenbank serialisiert wird. Rehydrierung ist das Gegenteil dieses Prozesses: Deserialisieren des letzten ausgeführten Zustands einer Orchestrierung aus der Datenbank. Mit dem Pausieren soll die Inanspruchnahme von Systemressourcen minimiert werden, indem man die Anzahl der Orchestrierungen verringert, die gleichzeitig im Speicher instanziiert sein müssen. Die Engine pausiert die Instanz, indem sie den Status speichert, und gibt den von der Instanz belegten Speicherplatz frei. Indem es ruhende Orchestrierungsinstanzen pausiert, ermöglicht die Engine auf demselben Computer das gleichzeitige Ausführen zahlreicher Geschäftsprozesse mit langer Laufzeit. Bei dieser Analyse wird auf einen steigenden Trend von einer Leerlauforchestrierung pro Stunde überprüft. Referenz: Orchestrierungshydrierung und Rehydrierung.
BizTalk Server: Eingehende BizTalk-Latenz	Durchschnittliche Latenzzeit in Millisekunden ab dem Empfang eines Dokuments vom Adapter durch die Messaging-Engine bis zum Zeitpunkt der Veröffentlichung im MessageBox-Objekt. Die Verringerung der Latenz ist für einige Benutzer von BizTalk wichtig, daher ist es wichtig, die Zeit zu verfolgen, die Dokumente im eingehenden Adapter verbringen. Weitere Informationen finden Sie unter BizTalk Inbound Latency Analysis in diesem Thema.
BizTalk Server: BizTalk-Nachrichtenübermittlungsverzögerung	Dies ist die aktuelle Verzögerung in Millisekunden (ms), die für jeden Nachrichtenübermittlungsbatch (gilt, wenn die Nachrichtenübermittlung gedrosselt wird). In Bezug auf die Drosselung wird eine Verzögerung bei der Veröffentlichung oder Verarbeitung der Nachricht angewendet, je nachdem, ob die Nachricht ein- oder ausgehend ist. Der Verzögerungszeitraum ist proportional zum Schweregrad der Einschränkungsbedingung. Drosselungsbedingungen mit höherem Schweregrad initiieren eine längere Drosselungsdauer als bedingungen mit niedrigerem Schweregrad. Diese Einschränkungsdauer wird innerhalb bestimmter Bereiche an die sich ändernden Bedingungen nach oben und unten angepasst. Der aktuelle Verzögerungszeitraum wird über die Leistungsindikatoren nachrichtenübermittlungsverzögerung (ms) und Nachrichtenveröffentlichungsverzögerung (ms) verfügbar gemacht, die der Leistungsobjektkategorie BizTalk:Message Agent zugeordnet sind. Bei dieser Analyse wird auf eine Verzögerung der Nachrichtenübermittlung von mehr als 5 Sekunden überprüft. Lange Verzögerungen bei der Nachrichtenübermittlung können auf eine starke Drosselung aufgrund hoher Last hindeuten. Referenz: Wie BizTalk Server die Hostdrosselung implementiert.
BizTalk Server: Status der BizTalk-Nachrichtenübermittlungsdrosselung	Der Status der BizTalk-Nachrichtenübermittlungsdrosselung ist einer der primären Indikatoren für die Drosselung. Es handelt sich um ein Flag, das angibt, ob das System die Nachrichtenübermittlung drosselt (was sich auf die XLANG-Nachrichtenverarbeitung und ausgehende Transporte auswirkt). Die Einschränkungsbedingung wird durch den numerischen Wert des Zählers angegeben. Weitere Informationen finden Sie unter BizTalk Message Delivery Drosselling State Analysis in diesem Thema.
BizTalk Server: Verzögerung bei der Veröffentlichung von BizTalk-Nachrichten	Die Verzögerung, die in jeden qualifizierenden Batch eingefügt wird, um die Veröffentlichung von Nachrichten zu drosseln. In Bezug auf die Drosselung wird eine Verzögerung bei der Veröffentlichung oder Verarbeitung der Nachricht angewendet, je nachdem, ob die Nachricht ein- oder ausgehend ist. Der Verzögerungszeitraum ist proportional zum Schweregrad der Einschränkungsbedingung. Drosselungsbedingungen mit höherem Schweregrad initiieren eine längere Drosselungsdauer als bedingungen mit niedrigerem Schweregrad. Diese Einschränkungsdauer wird innerhalb bestimmter Bereiche an die sich ändernden Bedingungen nach oben und unten angepasst. Der aktuelle Verzögerungszeitraum wird über die Leistungsindikatoren nachrichtenübermittlungsverzögerung (ms) und Nachrichtenveröffentlichungsverzögerung (ms) verfügbar gemacht, die der Leistungsobjektkategorie BizTalk:Message Agent zugeordnet sind. Bei dieser Analyse wird auf eine Verzögerung bei der Nachrichtenveröffentlichung von mehr als 5 Sekunden überprüft. Lange Verzögerungen bei der Nachrichtenübermittlung können auf eine starke Drosselung aufgrund hoher Last hindeuten. Referenz: Wie BizTalk Server die Hostdrosselung implementiert.
BizTalk Server: BizTalk MessageBox-Datenbankverbindungsfehler	Dieser Leistungsindikator gibt die Anzahl der versuchten Datenbankverbindungen an, die seit dem Start des Hosts instance fehlgeschlagen sind. Wenn der SQL Server Dienst, der die BizTalk-Datenbanken hostt, aus irgendeinem Grund nicht verfügbar ist, überträgt der Datenbankcluster Ressourcen vom aktiven Computer auf den passiven Computer. Während dieses Failoverprozesses treten bei den BizTalk Server-Dienstinstanzen Datenbankverbindungsfehler auf. Die Instanzen werden automatisch neu gestartet, um die Datenbankverbindung wiederherzustellen. Der funktionierende Datenbankcomputer (der zuvor passive Computer) beginnt mit der Verarbeitung der Datenbankverbindungen nach Übernahme der Ressourcen während des Failovers. Weitere Informationen finden Sie in diesem Thema unter Analyse von BizTalk MessageBox-Datenbankverbindungsfehlern.
BizTalk Server: BizTalk Messaging Latency: Request Response Latency	Die durchschnittliche Wartezeit (in Millisekunden) ab dem Zeitpunkt, zu dem die Messaging-Engine ein Anforderungsdokument vom Adapter empfängt, bis zum Versand eines Antwortdokuments an den Adapter. Sehen Sie sich das Diagramm an, das zeigt, wie die Latenz in der BizTalk-Analyse der eingehenden Latenz in diesem Thema gemessen wird. Bei einer Umgebung mit geringer Latenz wird bei dieser Analyse nach einer Request-Response Latenz von mehr als 5 Sekunden überprüft. Dies kann auf eine Verarbeitungsverzögerung zwischen dem eingehenden Adapter und dem ausgehenden Adapter hinweisen. Referenzen: - Anforderungs-/Antwortnachrichten - Skalieren Ihrer Lösungen
BizTalk Server: Veröffentlichungsstatus von BizTalk-Messaging	Der Status der Veröffentlichung von BizTalk-Nachrichten ist einer der primären Indikatoren für die Drosselung. Es handelt sich um ein Flag, das angibt, ob das System die Nachrichtenveröffentlichung drosselt (auswirkungen auf die XLANG-Nachrichtenverarbeitung und eingehende Transporte). Weitere Informationen finden Sie unter BizTalk Messaging Publishing Drosselling State Analysis in diesem Thema.
BizTalk Server: Angehaltene BizTalk-Orchestrierung/Sekunde	Eine angehaltene Nachricht ist ein instance einer Nachricht oder Orchestrierung, die BizTalk Server die Verarbeitung aufgrund eines Fehlers im System oder der Nachricht beendet hat. Instanzen, die aufgrund eines Systemfehlers angehalten wurden, können in der Regel nach Behebung des Systemproblems wieder aufgenommen werden. Instanzen, die aufgrund eines Nachrichtenfehlers angehalten wurden, können häufig nicht wieder aufgenommen werden. In diesem Fall muss die Nachricht selbst repariert und erneut an das BizTalk Server-System übermittelt werden. Bei dieser Analyse wird auf angehaltene Nachrichten/Orchestrierungen überprüft. Referenzen: - Überwachen von Integrität und Leistung BizTalk Server - Problembehandlung bei Microsoft BizTalk Server
BizTalk Server: BizTalk-Orchestrierungen abgeschlossen/Sekunde	Dies ist die Anzahl der BizTalk-Orchestrierungen, die pro Sekunde abgeschlossen wurden. Dies ist ein guter Indikator dafür, wie viel Durchsatz BizTalk verarbeitet. Diese Analyse stellt nur Statistiken bereit. Referenz: Skalieren Ihrer Lösungen
BizTalk Server: Verworfene BizTalk-Orchestrierungen	Die Anzahl der Orchestrierungsinstanzen, die seit dem Start der Hostinstanz aus dem Speicher verworfen wurden. Eine Orchestrierung kann verworfen werden, wenn die Engine ihren Status nicht sichern kann. Bei dieser Analyse wird auf verworfene Nachrichten überprüft. Referenz: WebLog der BizTalk Core-Engine
BizTalk Server: BizTalk Orchestrations Resident in Memory	Die Anzahl der Orchestrierungsinstanzen, die derzeit von der Hostinstanz gehostet werden. Bei dieser Analyse wird überprüft, ob die im Arbeitsspeicher ansässigen Orchestrierungen einen steigenden Trend aufweisen und ob mehr als 50 Prozent der im Arbeitsspeicher ansässigen Orchestrierungen nicht dehydrierbar sind. Weitere Informationen finden Sie unter BizTalk Orchestrations Resident in Memory Analysis.
BizTalk Server: Latenz des ausgehenden BizTalk-Adapters	Dies ist die durchschnittliche Wartezeit in Sekunden zwischen dem Abrufen eines Dokuments von der Messaging-Engine und dem Zeitpunkt, zu dem es vom Adapter gesendet wird. Sehen Sie sich das Diagramm an, das zeigt, wie die Latenz in der BizTalk-Analyse der eingehenden Latenz in diesem Thema gemessen wird. Bei einer Umgebung mit geringer Latenz wird bei dieser Analyse überprüft, ob im ausgehenden Adapter eine Latenz von durchschnittlich mehr als 5 Sekunden liegt. Dies kann auf eine Verarbeitungsverzögerung beim Transport von Nachrichten über ausgehende Adapter in diesem Host instance. Wenn in diesem Host mehrere ausgehende Adapter instance vorhanden sind, sollten Sie sie in ihre eigenen Hosts unterteilen, um zu ermitteln, welcher ausgehende Adapter eine hohe Latenz aufweist. Referenzen: - Anforderungs-/Antwortnachrichten. - BizTalk Server 2006: Fallstudie zur Skalierbarkeit mithilfe des SOAP-Adapters in BizTalk Server 2006 - Identifizieren von Engpässen im BizTalk-Tarif - Optimierungen von Szenarien mit niedriger Latenz für BizTalk Server
BizTalk Server: Ausstehende BizTalk-Nachrichten	Die Anzahl der empfangenen Nachrichten, die nicht als empfangen an messageBox bestätigt wurden. Ausstehende Nachrichten sind Nachrichten, die in den Arbeitsspeicher pullt und an die XLANG-Orchestrierung übermittelt wurden, aber noch nicht verarbeitet wurden. Dieser Umstand hat nichts mit Datenverlust zu tun. Das Übermitteln einer Nachricht an eine Orchestrierung ist ein mehrstufiger Prozess und einfach eine instance der Nachricht, die sich in der Spooltabelle der Datenbank befindet. Diese ausstehenden Nachrichten zählen als prozessinterne Nachrichten; Daher kann eine große Anzahl von ihnen im Arbeitsspeicher zu einer Speicherdrosselung auf dem System führen. Das Anpassen der Einstellung Interne Nachrichtenwarteschlangengröße kann dabei helfen, die Anzahl der ausstehenden Nachrichten zu steuern. Die Einstellung In-Process Nachrichten pro CPU wirkt sich darauf aus, wann die Drosselung aufgerufen wird, wenn eine hohe Anzahl von ausstehenden Nachrichten auftritt. Diese Einstellung finden Sie in den Hosteigenschaften in der BizTalk-Verwaltungskonsole. Diese Analyseüberprüfungen zeigen nur Statistiken für diesen Leistungsindikator an. Referenz: Leistungsindikatoren der Orchestrierungs-Engine.
BizTalk Server: BizTalk-Persistenzpunkte/Sekunde	Die durchschnittliche Anzahl der pro Sekunde dauerhaft gesicherten Orchestrierungsinstanzen. Die Orchestrierungs-Engine speichert den Status einer laufenden Orchestrierungsinstanz zu verschiedenen Zeitpunkten. Wenn die Orchestrierung instance reaktiviert, nach einem kontrollierten Herunterfahren gestartet oder nach einem unerwarteten Herunterfahren wiederhergestellt werden muss, wird die Orchestrierung instance vom letzten Persistenzpunkt ausgeführt. Um eine Orchestrierung instance beizubehalten, müssen alle Objektinstanzen, auf die sich Ihre Orchestrierung direkt oder indirekt bezieht (wie über andere Objekte), serialisierbar sein. Wenn die Nachrichtenpersistenzhäufigkeit zunimmt (wie oft Daten beibehalten werden müssen) nimmt die Gesamtleistung ab. In der Tat ist jeder Persistenzpunkt ein Roundtrip zur Datenbank, sodass die Häufigkeit von Persistenzpunkten nach Möglichkeit reduziert wird, indem Sie Persistenzpunkte vermeiden oder konsolidieren. Weitere Informationen dazu, wann Persistenzpunkte auftreten, finden Sie in den folgenden Verweisen. Bei dieser Analyse wird im Durchschnitt auf mehr als 10 Persistenzpunkte pro Sekunde überprüft. Dies ist ein allgemeiner Ausgangspunkt. Referenzen: - Persistenz in Orchestrierungen - Persistenz und die Orchestrierungs-Engine
BizTalk Server: Private BizTalk Bytes	Dies ist die Megabyte des zugeordneten privaten Arbeitsspeichers für den Host instance und vergleichbar mit dem Leistungsindikator "\Process(*)\Private Bytes". Diese Analyse bestimmt, ob eine der Hostinstanzen eine große Größe des Systemarbeitsspeichers verbraucht und ob der Host instance im Laufe der Zeit zunimmt. Weitere Informationen finden Sie unter BizTalk Private Bytes Analysis in diesem Thema.
BizTalk Server: BizTalk-Spooltabellengröße	Die MessageBox-Spooltabelle enthält einen Datensatz für jede Nachricht im System (aktiv oder wartet auf "Garbage Collection"). Die Überwachung der Anzahl der Zeilen in dieser Tabelle und der Anzahl der pro Sekunde empfangenen Nachrichten bei gleichzeitiger Erhöhung der Systemlast bietet eine einfache Möglichkeit, den maximalen dauerhaften Durchsatz zu ermitteln. Erhöhen Sie einfach die Eingabelast, bis entweder 1) die Spooltabelle unbestimmt zu wachsen beginnt, oder 2) die Anzahl der empfangenen Nachrichten pro Sekunde, je nachdem, was zuerst eintritt, und das ist Ihr maximaler nachhaltiger Durchsatz. Zusammenfassend lässt sich sagen, dass dieses Measure unabhängig von anderen Indikatoren ihnen eine schnelle und einfache Möglichkeit gibt, zu beurteilen, ob Ihr System überlastet wird oder nicht. Wenn die Größe der BizTalk-Spooltabellen einen steigenden Trend aufweist, kann es aufgrund einer unausgeglichenen Nachrichtenübermittlungsrate (Eingaberate überschreitet die Ausgaberate) oder zu einer Drosselung aufgrund der Datenbankgröße kommen. Bei dieser Analyse wird auf einen steigenden Trend in der BizTalk-Spooltabellengröße überprüft. Referenzen: - Grundlegendes zu Durchsatz und Kapazität BizTalk Server 2004 SP1 - Nachhaltiger Auslastungstest - Empfehlungen beim Testen der Engine-Leistung.
BizTalk Server: BizTalk-Nachverfolgungsdatengröße	Da BizTalk Server immer mehr Daten auf Ihrem System verarbeitet, wird die BizTalk-Nachverfolgungsdatenbank (BizTalkDTADb) immer größer. Ein unkontrolliertes Anwachsen dieser Datenbank wirkt sich nachteilig auf die Systemleistung aus und kann zu Fehlern im TDDS-Dienst (Tracking Data Delivery Service) führen. Neben allgemeinen Überwachungsdaten können sich auch überwachte Nachrichten in der MessageBox-Datenbank ansammeln, was eine Verschlechterung der Festplattenleistung zur Folge hat. Bei dieser Analyse wird ein steigender Trend von mehr als 5 MB pro Stunde in der Größe der Nachverfolgungsdaten überprüft. Referenz: Archivieren und Löschen der BizTalk-Nachverfolgungsdatenbank
BizTalk Server: BizTalk-Transaktionsbereiche abgebrochen	Dies ist die Anzahl von lang andauernden oder atomaren Bereichen, die abgebrochen wurden, seit der Host instance gestartet wurde. Ein Transaktionsbereichabbruch ist ein Fehler, der in einem Transaktionsbereich innerhalb einer Orchestrierung auftritt. Es ist wichtig zu verstehen, dass der Kompensationshandler eines Bereichs nur aufgerufen wird, wenn der Bereich erfolgreich abgeschlossen wurde, aber dann rückgängig gemacht werden muss, da ein umgebender Bereich beschlossen hat, abzubrechen (aufgrund von Fehlern, die später im Prozess auftreten können). Außerdem tritt im Falle eines Transaktionsabbruchs kein automatisches Rollback des Zustands auf. Sie können dieses Ergebnis programmgesteuert über die Ausnahme- und Kompensationshandler erreichen. Transaktionsbereichsabbrüche sollten in einer Produktionsumgebung normalerweise nicht auftreten. Daher wird bei dieser Analyse überprüft, ob transaktionsbezogene Bereiche abgebrochen werden. Referenz: Transaktionen
BizTalk Server: BizTalk-Transaktionsbereiche kompensiert	Die Entschädigung kann als logisches Rückgängigmachen der Arbeit betrachtet werden, die als Reaktion auf eine Fehlerbedingung erfolgreich ausgeführt wurde. Es ist wichtig zu verstehen, dass der Kompensationshandler eines Bereichs nur aufgerufen wird, wenn der Bereich erfolgreich abgeschlossen wurde, aber dann rückgängig gemacht werden muss, da ein umgebender Bereich beschlossen hat, abzubrechen (aufgrund von Fehlern, die später im Prozess auftreten können). Außerdem tritt im Falle eines Transaktionsabbruchs kein automatisches Rollback des Zustands auf. Mithilfe der Ausnahme- und Kompensationshandler können Sie ein Rollback programmgesteuert ausführen. Transaktionsbereichskompensationen sollten normalerweise nicht in einer Produktionsumgebung erfolgen. Daher wird bei dieser Analyse überprüft, ob transaktionsbezogene Bereiche abgebrochen werden. Referenz: Transaktionen
BizTalk Server: Virtuelle BizTalk-Bytes	Dies sind die Megabyte, die für den virtuellen Arbeitsspeicher für den Host instance reserviert sind. Diese Analyse bestimmt, ob eine der Hostinstanzen eine große Menge des Systemspeichers verbraucht und ob der Host instance im Laufe der Zeit den Arbeitsspeicherverbrauch erhöht. Weitere Informationen finden Sie unter BizTalk Virtual Bytes Analysis in diesem Thema.
BizTalk Server: Sitzungsdrosselung der BizTalk-Nachrichten-Agent-Datenbank	Dies ist die Anzahl der offenen Datenbankverbindungen für messageBox im Vergleich zu der jeweiligen BizTalk-Einschränkungseinstellung. "Datenbankverbindung pro CPU" ist die maximale Anzahl gleichzeitiger Datenbanksitzungen (pro CPU), die vor Beginn der Drosselung zulässig ist. Weitere Informationen finden Sie unter Analyse der Sitzungsdrosselung der BizTalk-Nachrichten-Agent-Datenbank in diesem Thema.
BizTalk Server: Schwellenwert für die BizTalk-Nachrichten-Agent-Datenbank-Sitzungsdrosselung	Dies ist der aktuelle Schwellenwert für die Anzahl der geöffneten Datenbankverbindungen für messageBox. "Datenbankverbindung pro CPU" ist die maximale Anzahl gleichzeitiger Datenbanksitzungen (pro CPU), die vor Beginn der Drosselung zulässig ist. Weitere Informationen finden Sie unter BizTalk Message Agent Database Session Drosselling Threshold Analysis in diesem Thema.
BizTalk Server: BizTalk-Nachrichten-Agent In-Process-Nachrichtenanzahl Drosselung	Dies ist die Anzahl gleichzeitiger Nachrichten, die von der Dienstklasse verarbeitet werden. Die Einstellung "In-process messages per CPU" in the Host Drosselling Settings (Host Drosselling Settings) ist die maximale Anzahl von Nachrichten, die an den Endpunkt-Manager (EPM) oder XLANG übermittelt wurden, die nicht verarbeitet wurden. Weitere Informationen finden Sie unter BizTalk-Nachrichten-Agent In-process Message Count Drosselung Analysis in diesem Thema.
BizTalk Server: BizTalk-Nachrichten-Agent In-Process-Nachrichtenanzahl Drosselungsschwellenwert	Dies ist der aktuelle Schwellenwert für die Anzahl gleichzeitiger Nachrichten, die von der Dienstklasse verarbeitet werden. Die Einstellung "In-process messages per CPU" in the Host Drosselling Settings (Host Drosselling Settings) ist die maximale Anzahl von Nachrichten, die an den Endpunkt-Manager (EPM) oder XLANG übermittelt wurden, die nicht verarbeitet wurden. Weitere Informationen finden Sie in diesem Thema unter BizTalk-Nachrichten-Agent In-Process Message Count Drosselling Threshold Analysis .
BizTalk Server: Drosselung der Speicherauslastung (MB) des BizTalk-Nachrichten-Agents	Dies ist die Arbeitsspeicherauslastung des aktuellen Prozesses (MB). Die Speicherdrosselung des BizTalk-Prozesses kann auftreten, wenn der zu veröffentlichende Batch hohe Speicheranforderungen aufweist oder wenn zu viele Threads Nachrichten verarbeiten. Weitere Informationen finden Sie in diesem Thema unter BizTalk Message Agent Process Memory Usage (MB) Drosselungsanalyse.For more information, the BizTalk Message Agent Process Memory Usage (MB) Drosselling Analysis in this topic.
BizTalk Server: BizTalk Message Agent Process Memory Usage (MB) Drosselungsschwellenwert	Dies ist der aktuelle Schwellenwert für die Arbeitsspeicherauslastung des aktuellen Prozesses (MB). Der Schwellenwert kann dynamisch angepasst werden, abhängig von der tatsächlichen Menge an Arbeitsspeicher, die für diesen Prozess verfügbar ist, und seinem Speicherverbrauchsmuster. Die Speicherdrosselung des BizTalk-Prozesses kann auftreten, wenn der zu veröffentlichende Batch hohe Speicheranforderungen aufweist oder wenn zu viele Threads Nachrichten verarbeiten. Weitere Informationen finden Sie unter BizTalk Message Agent Process Memory Usage (MB) Drosselung Schwellenwertanalyse in diesem Thema.
BizTalk Server: Drosselung der Threadanzahl des BizTalk-Nachrichten-Agents	Die Gesamtanzahl der Threads im BizTalk-Prozess. "Threads pro CPU" ist die Gesamtanzahl der Threads im Hostprozess, einschließlich threads, die von Adaptern verwendet werden. Wird dieser Schwellenwert überschritten, versucht BizTalk Server, die Größe des EPM-Threadpools und des Threadpools des Nachrichtenagenten zu reduzieren. In Szenarien, in denen eine hohe Last zum Erstellen einer großen Anzahl von Threads führen kann, sollte die threadbasierte Einschränkung aktiviert werden. Dieser Parameter wirkt sich auf die Einschränkung eingehender und ausgehender Nachrichten aus. Threadbasierte Drosselung ist standardmäßig deaktiviert. Bei dieser Analyse wird überprüft, ob die Anzahl des BizTalk-Threads größer als 80 Prozent des Grenzwerts für die Einschränkung ist, der eine Einschränkungsbedingung angibt. Referenzen: - Hostdrosselungsleistungsindikatoren - Implementieren der Hostdrosselung BizTalk Server - Ändern der Standardeinstellungen für die Hostdrosselung - Konfigurationsparameter, die sich auf die Adapterleistung auswirken - Threads, DB-Sitzungen und Drosselung
BizTalk Server: Schwellenwert für die Threadanzahl des BizTalk-Nachrichten-Agents	Dies ist der aktuelle Schwellenwert für die Gesamtanzahl von Threads im Prozess. "Threads pro CPU" ist die Gesamtanzahl der Threads im Hostprozess, einschließlich threads, die von Adaptern verwendet werden. Wird dieser Schwellenwert überschritten, versucht BizTalk Server, die Größe des EPM-Threadpools und des Threadpools des Nachrichtenagenten zu reduzieren. Threadbasierte Drosselung sollte in Szenarien aktiviert werden, in denen eine hohe Auslastung zur Erstellung einer großen Anzahl von Threads führen kann. Dieser Parameter wirkt sich auf die Einschränkung eingehender und ausgehender Nachrichten aus. Bei dieser Analyse wird überprüft, ob diese Einschränkungseinstellung auf einen Nicht-Standardwert festgelegt ist. Threadbasierte Drosselung ist standardmäßig deaktiviert. Referenzen: - Hostdrosselungsleistungsindikatoren - Implementieren der Hostdrosselung BizTalk Server - Ändern der Standardeinstellungen für die Hostdrosselung - Konfigurationsparameter, die sich auf die Adapterleistung auswirken - Threads, DB-Sitzungen und Drosselung

Analyse der Lese-/Schreibwartezeit logischer/physischer Datenträger

Die zuverlässigste Möglichkeit für Windows, einen Datenträgerleistungsengpass zu erkennen, ist die Messung der Antwortzeiten. Wenn die Antwortzeiten größer als .025 (25 Millisekunden) sind, was ein konservativer Schwellenwert ist, können spürbare Verlangsamungen und Leistungsprobleme auftreten, die sich auf Benutzer auswirken.

Häufige Ursachen für schlechte Datenträgerlatenz sind Datenträgerfragmentierung, Leistungscache, ein übersättigungtes SAN und eine zu große Last auf dem Datenträger. Verwenden Sie das SPA-Tool, um die wichtigsten Dateien und Prozesse zu identifizieren, die den Datenträger verwenden. Überprüfen Sie auch die "Prozess-E/a-Datenvorgänge/s" und "Weitere Vorgänge/Sek. verarbeiten", um zu ermitteln, welche Prozesse die meisten Datenträger-E/A-Vorgänge verbrauchen. Beachten Sie, dass Leistungsindikatoren nicht angeben können, welche Dateien beteiligt sind.

Referenzen

• Ausschließen von Disk-Bound Problemen

• Identifizieren eines Datenträgerleistungsengpasses mithilfe des Microsoft Server Performance Advisor-Tools (SPA)

• Herunterladen von Details für Microsoft Service Performance Advisor (SPA)

Logische Datenträgerübertragungen/s

"Datenträgerübertragungen/s" ist die Rate von Lese- und Schreibvorgängen auf dem Datenträger. Datenträgerübertragungen stellen zwar keine direkte Korrelation mit Datenträger-E/A-Vorgängen her, geben aber an, wie viele Datenträgervorgänge ausgeführt werden. Wenn Sie sequenzielle E/A-Vorgänge und zufällige E/A-Vorgänge durchschnittliche, dann haben Sie als allgemeine Faustregel ungefähr 80 E/A pro Sekunde. Daher sollten wir davon ausgehen, dass ein SAN-Laufwerk unter Last mehr als 80 E/A-Vorgänge pro Sekunde ausführt. Die Schwellenwerte für diese Analyse überprüfen, ob einer der logischen Datenträger schlechte Antwortzeiten (mehr als 25 ms Antwortzeiten für E/A-Vorgänge) anzeigt. Wenn dies zutrifft, sollten wir davon ausgehen, dass die Datenträgerübertragungen pro Sekunde bei oder über 80 liegen. Andernfalls muss die Datenträgerarchitektur untersucht werden. Die häufigste Ursache für schlechte Datenträger-E/A-Vorgänge ist die LUN-Überladung (Logical Unit Number, Logische Einheitennummer) auf dem SAN, d. h. die Bedingung, bei der mehr als eine LUN das kleine physische Datenträgerarray verwendet.

Verfügbare Speicheranalyse

"Verfügbare Mbytes" ist die Menge des physischen Arbeitsspeichers, der für prozesse, die auf dem Computer ausgeführt werden, in Megabytes verfügbar ist. Der Virtual Memory Manager passt den im physischen Arbeitsspeicher und auf dem Datenträger belegten Speicherplatz kontinuierlich an, um eine minimale Anzahl verfügbarer Bytes für das Betriebssystem und die Prozesse beizubehalten. Wenn genügend Bytes verfügbar sind, lässt der Virtual Memory Manager die Arbeitssätze von Prozessen wachsen oder hält sie stabil, indem für jede neu hinzugefügte Seite eine alte Seite entfernt wird. Wenn nur wenige Bytes verfügbar sind, muss der Virtual Memory Manager die Arbeitssätze von Prozessen kürzen, um das erforderliche Minimum beizubehalten.

Bei dieser Analyse wird überprüft, ob der gesamte verfügbare Arbeitsspeicher gering ist– Warnung bei 10 Prozent verfügbar und Kritisch bei 5 Prozent verfügbar. Eine Warnung wird auch ausgegeben, wenn ein abnehmender Trend von 10 MB pro Stunde erkannt wird, was auf eine potenzielle bevorstehende Arbeitsspeicherbedingung hinweist. Ein geringer physischer Arbeitsspeicher kann zu erhöhten CPU- und Systemverzögerungen im privilegierten Modus führen.

Referenzen

• Ausschließen von Memory-Bound Problemen

Analyse der Speicherleckerkennung

Bei dieser Analyse wird ermittelt, ob einer der Prozesse einen großen Teil des Systemspeichers verbraucht und ob der Speicherverbrauch im Laufe der Zeit zunimmt. Ein Prozess, der große Teile des Arbeitsspeichers verbraucht, ist in Ordnung, solange der Prozess den Arbeitsspeicher an das System zurückgibt. Suchen Sie im Diagramm nach steigenden Trends. Ein zunehmender Trend über einen längeren Zeitraum kann auf einen Speicherverlust hinweisen. Private Bytes ist die aktuelle Größe des Arbeitsspeichers in Bytes, den dieser Prozess zugewiesen hat und der nicht für andere Prozesse freigegeben werden kann. Bei dieser Analyse wird überprüft, ob 10 MB pro Stunde und 5 MB pro Stunde trends steigen. Verwenden Sie diese Analyse in Korrelation mit der Analyse verfügbaren Arbeitsspeichers.

Denken Sie auch daran, dass neu gestartete Prozesse zunächst als Speicherverlust angezeigt werden, wenn es sich einfach um ein normales Startverhalten handelt. Ein Speicherverlust tritt auf, wenn ein Prozess weiterhin Arbeitsspeicher verbraucht und über einen längeren Zeitraum keinen Arbeitsspeicher freigibt.

Wenn Sie einen Speicherverlust vermuten, installieren Und verwenden Sie das Debugdiagnosetool. Weitere Informationen zum Debugdiagnosetool finden Sie im Abschnitt verweise.

Verweis

Debugdiagnosetool

Analyse von Speicherseiten/Sekunde

Bei dieser Analyse wird überprüft, ob die "Seiten/Sekunde" hoch ist. Wenn es hoch ist, ist dem System wahrscheinlich der Arbeitsspeicher nicht mehr verfügbar, indem versucht wird, den Arbeitsspeicher auf den Datenträger auszugeben. "Seiten/Sekunde" ist die Rate, mit der Seiten aus dem Datenträger gelesen oder auf den Datenträger geschrieben werden, um fehlerbehaftete Seiten zu beheben. Dieser Leistungsindikator ist ein wesentlicher Indikator für Fehler, die systemweite Verzögerungen verursachen. Dies ist die Summe aus "Arbeitsspeicher\Seiteneingabe/Sekunde" und "Arbeitsspeicher\Seitenausgabe/Sekunde". Es wird in Anzahl von Seiten gezählt, sodass er mit anderen Seitenanzahlen verglichen werden kann, z. B. "Arbeitsspeicher\Seitenfehler/Sekunde".

Dieser Zähler sollte immer unter 1.000 liegen. Bei dieser Analyse werden Werte über 1.000 überprüft. Verwenden Sie diese Analyse in Korrelation mit der Analyse des verfügbaren Arbeitsspeichers und der Analyse der Speicherleckerkennung. Wenn alle Analysen gleichzeitig Warnungen auslösen, kann dies darauf hindeuten, dass dem System der Arbeitsspeicher knapp wird. Führen Sie die Analyseschritte aus, die unter Zusätzliche Informationen zur Analyse der Speicherleckerkennung in diesem Thema beschrieben sind.

Verweis

Ausschließen von Memory-Bound Problemen

Analyse der speicherresidenten Bytes des Arbeitsspeichercaches

"Systemcache Resident Bytes" ist die Größe des auslagerungsfähigen Betriebssystemcodes im Dateisystemcache in Bytes. Dieser Wert umfasst nur aktuelle physische Seiten, nicht aber virtuelle Speicherseiten, die gegenwärtig nicht resident sind. Er entspricht dem im Task-Manager angezeigten Systemcachewert. Daher kann dieser Wert kleiner sein als die tatsächliche Menge an virtuellem Arbeitsspeicher, die vom Dateisystemcache verwendet wird. Dieser Wert ist eine Komponente von "Memory\\System Code Resident Bytes", die den gesamten auslagerungsfähigen Betriebssystemcode darstellt, der sich derzeit im physischen Arbeitsspeicher befindet. Dieser Indikator zeigt nur den zuletzt ermittelten Wert an, keinen Durchschnittswert.

Diese Analyse überprüft einen steigenden Trend von 10 MB pro Stunde. Unter Last kann ein Server den Systemcache verwenden, um E/A-Aktivitäten wie z. B. Datenträger zwischenzuspeichern. Verwenden Sie in Korrelation mit Process-E/A-Datenvorgängen/s und Prozess-E/A Sonstige Vorgänge/Sekunde-Analysen.

Prozessorauslastungsanalyse und übermäßige Prozessornutzung durch Prozesse

"% Prozessorzeit" ist der Prozentsatz der verstrichenen Zeit, die der Prozessor für die Ausführung eines Threads ohne Leerlauf aufwendet. Sie wird berechnet, indem die Dauer gemessen wird, für die der Thread im Leerlauf im Stichprobenintervall aktiv ist, und dann diese Zeit von der Intervalldauer subtrahiert wird. (Jeder Prozessor verfügt über einen Leerlaufthread, der Zyklen nutzt, wenn keine anderen Threads ausgeführt werden können.) Dieser Indikator ist der primäre Indikator für die Prozessoraktivität und zeigt den durchschnittlichen Prozentsatz der Während des Stichprobenintervalls beobachteten Auslastungszeit an. Er wird berechnet, indem die Zeit überwacht wird, zu der der Dienst inaktiv ist, und dieser Wert von 100 Prozent subtrahiert wird.

Bei dieser Analyse wird überprüft, ob die Auslastung jedes einzelnen Prozessors größer als 60 Prozent ist. Wenn dies der Grund ist, bestimmen Sie, ob es sich um einen CPU-Modus mit hohem Benutzermodus oder einen Modus mit hohen Berechtigungen handelt. Wenn eine CPU mit hohem Privilegierten Modus vermutet wird, lesen Sie die Informationen unter "CPU-Analyse des privilegierten Modus". Wenn ein Prozessorengpass im Benutzermodus vermutet wird, sollten Sie einen Prozessprofiler verwenden, um die Funktionen zu analysieren, die den hohen CPU-Verbrauch verursachen. Weitere Informationen finden Sie im Abschnitt "Gewusst wie: Identifizieren von Funktionen, die einen hohen CPU-Engpass im Benutzermodus für Serveranwendungen in einer Produktionsumgebung verursachen".

Analyse der Länge der Prozessorwarteschlange

"Prozessorwarteschlangenlänge" ist die Anzahl der Threads in der Prozessorwarteschlange. Im Gegensatz zu den Datenträgerindikatoren zählt dieser Leistungsindikator nur die bereits abgeschlossenen und nicht die noch ausgeführten Threads. Auch bei Computern mit mehreren Prozessoren gibt es immer nur eine Warteschlange. Sie müssen diesen Wert daher durch die Anzahl der Prozessoren teilen, die für die Verarbeitung der Arbeitslast zur Verfügung stehen. Abhängig von der jeweiligen Arbeitsauslastung sollte die Prozessorwarteschlange normalerweise dauerhaft weniger als 10 Threads enthalten.

Diese Analyse bestimmt, ob die durchschnittliche Länge der Prozessorwarteschlange die Anzahl der Prozessoren überschreitet. Wenn dies der Fall ist, kann dies auf einen Prozessorengpass hinweisen. Verwenden Sie diese Analyse in Korrelation mit der CPU-Analyse im privilegierten Modus und der übermäßigen Prozessornutzung nach Prozess. Die Prozessorwarteschlange ist die Sammlung von Threads, die bereit sind, aber nicht vom Prozessor ausgeführt werden können, da derzeit ein anderer aktiver Thread ausgeführt wird. Eine dauerhafte oder wiederkehrende Warteschlange mit mehr Threads als der Anzahl von Prozessoren ist ein guter Hinweis auf einen Prozessorengpass.

Sie können diesen Indikator in Verbindung mit dem Zähler "Prozessor\% Prozessorzeit" verwenden, um zu bestimmen, ob Ihre Anwendung von weiteren CPUs profitieren kann. Es gibt eine einzelne Warteschlange für die Prozessorzeit, auch auf Computern mit mehreren Prozessoren. Teilen Sie daher auf einem Multiprozessorcomputer den Wert "Prozessorwarteschlangenlänge" (PQL) durch die Anzahl der Prozessoren, die die Workload verwalten.

Wenn die CPU sehr ausgelastet ist (90 Prozent und eine höhere Auslastung), und der PQL-Durchschnitt konsistent höher als die Anzahl der Prozessoren ist, kann es zu einem Prozessorengpass kommen, der von zusätzlichen CPUs profitieren kann. Alternativ können Sie die Anzahl der Threads und die Warteschlange auf Anwendungsebene reduzieren. Dies führt zu weniger Kontextwechseln, was sich gut zur Verringerung der CPU-Last eignet. Der häufige Grund für eine hohe PQL mit geringer CPU-Auslastung ist, dass Anforderungen für prozessorzeit zufällig eingehen und Threads unregelmäßige Zeit vom Prozessor verlangen. Dies bedeutet, dass der Prozessor kein Engpass ist. Stattdessen muss Ihre Threadinglogik verbessert werden.

Wenn ein Prozessorengpass im Benutzermodus vermutet wird, sollten Sie einen Prozessprofiler verwenden, um die Funktionen zu analysieren, die den hohen CPU-Verbrauch verursachen. Weitere Informationen finden Sie im Abschnitt "Gewusst wie: Identifizieren von Funktionen, die einen hohen CPU-Engpass im Benutzermodus für Serveranwendungen in einer Produktionsumgebung verursachen".

CPU-Analyse im privilegierten Modus

Dieser Indikator gibt den Prozentsatz der Ausführungszeit eines Threads im privilegierten Modus an. Wenn Ihre Anwendung Betriebssystemfunktionen aufruft (z. B. zum Ausführen von Datei- oder Netzwerk-E/A oder zum Zuweisen von Arbeitsspeicher), werden diese Betriebssystemfunktionen im privilegierten Modus ausgeführt.

Die CPU mit hohem Privilegierten Modus gibt an, dass der Computer zu viel Zeit mit System-E/A-Vorgängen verbringt, im Vergleich zur realen Arbeit (Benutzermodus). "% Privileged Time" ist der Prozentsatz der verstrichenen Zeit, die die Prozessthreads mit der Ausführung von Code im privilegierten Modus verbracht haben. Wenn ein Windows-Systemdienst aufgerufen wird, wird der Dienst häufig im privilegierten Modus ausgeführt, um Zugriff auf systemprivate Daten zu erhalten. Diese Daten werden durch Threads, die im Benutzermodus ausgeführt werden, vor dem Zugriff geschützt. Aufrufe des Systems können explizit oder implizit sein, z. B. Seitenfehler oder Unterbrechungen. Im Gegensatz zu einigen frühen Betriebssystemen verwendet Windows zusätzlich zum herkömmlichen Schutz von Benutzer- und privilegierten Modi Prozessgrenzen für den Subsystemschutz. Einige Aufgaben, die Von Windows im Auftrag der Anwendung ausgeführt werden, können zusätzlich zur privilegierten Zeit im Prozess in anderen Subsystemprozessen angezeigt werden.

Bei dieser Analyse wird überprüft, ob die CPU im privilegierten Modus mehr als 30 Prozent der gesamten CPU verbraucht. Wenn ja, wird der CPU-Verbrauch wahrscheinlich durch einen anderen Engpass als den Prozessor verursacht, z. B. Netzwerk, Arbeitsspeicher oder Datenträger-E/A. Verwenden Sie in Korrelation mit Analysen zur Unterbrechungszeit in % und hohem Kontextwechsel.

Analyse des Wechsels mit hohem Kontext

Ein Kontextwechsel tritt auf, wenn ein Thread mit höherer Priorität einen Thread mit niedrigerer Priorität entfernt, der derzeit ausgeführt wird, oder wenn ein Thread mit hoher Priorität blockiert wird. Wenn viele Threads dieselbe Prioritätsstufe haben, können hohe Ebenen des Kontextwechsels auftreten. Dies weist häufig darauf hin, dass zu viele Threads um die Prozessoren im System konkurrieren. Wenn Sie nicht viel Prozessorauslastung sehen und sehr niedrige Ebenen des Kontextwechsels sehen, kann dies darauf hindeuten, dass Threads blockiert sind.

Ein hoher Kontextwechsel sollte nur untersucht werden, wenn die CPU im privilegierten Modus und die CPU insgesamt hoch sind. In der Regel sind Kontextwechselraten von weniger als 5.000 pro Sekunde und Prozessor keine Sorge wert. Wenn die Kontextwechselraten 15.000 pro Sekunde und Prozessor überschreiten, gibt es eine Einschränkung.

Bei dieser Analyse wird überprüft, ob systemkontextbezogene Wechsel pro Sekunde mit hoher CPU, hoher Privilegierter Modus und hoch (mehr als 5.000 pro Prozessor) gleichzeitig auftreten. Wenn ein hoher Kontextwechsel auftritt, verringern Sie die Anzahl der Threads und Prozesse, die auf dem System ausgeführt werden.

Analyse von BizTalk-Sitzungen mit hoher Datenbank

Dieser Indikator verfügt über zwei mögliche Werte: normal (0) oder überschritten (1). Bei dieser Analyse wird der Wert 1 überprüft. Wenn ja, hat BizTalk den Schwellenwert für die Anzahl der zulässigen Datenbanksitzungen überschritten. Dieser Wert wird durch den Wert "Datenbankverbindung pro CPU" in den Einstellungen für die BizTalk-Hostdrosselung gesteuert.

"Datenbankverbindung pro CPU" ist die maximale Anzahl gleichzeitiger Datenbanksitzungen (pro CPU), die vor Beginn der Drosselung zulässig sind. Datenbanksitzungen im Leerlauf im Allgemeinen Sitzungspool pro Host werden in diesen Wert nicht einbezogen. Für diesen Parameter ist ausschließlich die Anzahl der Sitzungen relevant, die tatsächlich von der Hostinstanz genutzt werden. Diese Option ist standardmäßig deaktiviert. In der Regel sollte diese Einstellung nur aktiviert werden, wenn der Datenbankserver ein Engpass ist oder für Low-End-Datenbankserver im BizTalk Server-System. Sie können die Anzahl der aktiven Datenbankverbindungen mithilfe des Leistungsindikators der Datenbanksitzung unter der Leistungsobjektkategorie BizTalk:Message Agent überwachen. Dieser Parameter wirkt sich nur auf die Einschränkung ausgehender Nachrichten aus. Geben Sie zum Deaktivieren der auf der Anzahl der Datenbanksitzungen basierenden Einschränkung den Wert 0 ein. Der Standardwert ist 0.

Hinweis

Der Registrierungsschlüssel "MaxWorkerThreads" beeinflusst die Anzahl der für BizTalk verfügbaren Threads und kann hilfreich sein, wenn die meisten BizTalk-Threads mit Datenbankverbindungen beschäftigt sind.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Threads, Datenbanksitzungen und Drosselung

• Konfigurationsparameter mit Auswirkung auf die Adapterleistung

• Ändern der Standardeinschränkungseinstellungen für den Host

BizTalk– Analyse der datenbankweiten Größe

Dieser Leistungsindikator bezieht sich auf die Anzahl der Nachrichten in den Datenbankwarteschlangen, die von diesem Prozess veröffentlicht wurden. Dieser Wert wird anhand der Anzahl von Elementen in den Warteschlangentabellen aller Hosts sowie der Anzahl von Elementen in den Spool- und Überwachungstabellen gemessen. Die Warteschlange umfasst die Arbeitswarteschlange, die Zustandswarteschlange und die angehaltene Warteschlange. Wenn ein Prozess Nachrichten in mehreren Warteschlangen veröffentlicht, spiegelt der Indikator den gewichteten Durchschnitt aller Warteschlangen wider.

Bei einem Neustart des Hosts gehen die Statistiken im Speicher verloren. Da ein gewisser Mehraufwand erforderlich ist, werden BizTalk Server nur dann wieder Statistiken sammeln, wenn mindestens 100 Veröffentlichungen vorhanden sind, wobei 5 Prozent der gesamten Veröffentlichungen innerhalb des neu gestarteten Hostprozesses enthalten sind.

Dieser Indikator wird auf den Wert 1 festgelegt, wenn eine der Bedingungen für die Nachrichtenanzahl im Datenbankschwellenwert auftritt. Dieser Schwellenwert ist im Thema Ändern der Standardeinstellungen für die Hostdrosselung dokumentiert, auf die weiter unten verwiesen wird. Standardmäßig ist die Anzahl der Hostnachrichten in der Datenbankdrosselung auf einen Wert von 50.000 festgelegt, wodurch unter den folgenden Umständen eine Drosselungsbedingung ausgelöst wird:

• Die Gesamtanzahl der Nachrichten, die von der Hostinstanz in der Warteschlange "Verarbeiten", der Statuswarteschlange und der Warteschlange "Angehalten" der abonnierenden Hosts veröffentlicht werden, übersteigt 50.000.

• Die Anzahl der Nachrichten in der Spool- oder der Überwachungstabelle übersteigt 50.000 Nachrichten.

  Da angehaltene Nachrichten in der Datenbankberechnung in die Nachrichtenanzahl einbezogen werden, kann die Nachrichtenveröffentlichung auch dann gedrosselt werden, wenn auf dem BizTalk-Server eine geringe oder keine Auslastung auftritt.

  Bei dieser Analyse wird der Wert 1 überprüft. In diesem Fall sollten Sie eine Vorgehensweise in Betracht ziehen, die die Anzahl der Nachrichten in der Datenbank reduziert. Stellen Sie beispielsweise sicher, dass die BizTalk-SQL Server Aufträge fehlerfrei ausgeführt werden, und verwenden Sie den Group Hub in der BizTalk-Verwaltungskonsole, um zu ermitteln, ob die Meldungserstellung durch eine große Anzahl an angehaltener Nachrichten verursacht wird.

Referenzen

• Angehaltene Nachrichten zählen zu der Anzahl der Nachrichten im Datenbank-Einschränkungsschwellenwert

• Ändern der Standardeinschränkungseinstellungen für den Host

• Leistungsindikatoren für die Hosteinschränkung

BizTalk High In-Process Message Count Analysis

Die Einstellung "In-process messages per CPU" (In-Process Messages per CPU) in den Hostdrosselungseinstellungen ist die maximale Anzahl von Nachrichten, die an den Endpunkt-Manager (EPM) oder XLANG übermittelt werden, die nicht verarbeitet wurden. Diese Zahl enthält nicht die Nachrichten, die aus der Datenbank abgerufen wurden, aber immer noch auf die Übermittlung in der In-Memory-Warteschlange warten. Sie können die Anzahl von In-Process-Nachrichten überwachen, indem Sie den Leistungsindikator Für die Anzahl von In-Process-Nachrichten unter der Leistungsobjektkategorie BizTalk:Message Agent verwenden. Dieser Parameter bietet einen Hinweis auf den Drosselungsmechanismus, wenn Drosselungsbedingungen berücksichtigt werden. Der eigentliche Schwellenwert unterliegt der Selbstoptimierung. Sie können den tatsächlichen Schwellenwert überprüfen, indem Sie den Leistungsindikator für die Nachrichtenanzahl in Prozessen überwachen.

Dieser Parameter kann auf einen kleineren Wert für große Nachrichtenszenarien festgelegt werden, bei denen entweder die durchschnittliche Nachrichtengröße hoch ist oder die Verarbeitung von Nachrichten eine große Anzahl von Nachrichten erfordert. Dies ist offensichtlich, wenn in einem Szenario zu oft eine speicherbasierte Drosselung auftritt und der Arbeitsspeicherschwellenwert automatisch auf einen wesentlich niedrigen Wert angepasst wird. Ein solches Verhalten zeigt an, dass die Zahl der vom ausgehenden Transport gleichzeitig verarbeiteten Nachrichten reduziert werden sollte, um eine zu hohe Speicherauslastung zu vermeiden. In Szenarien, in denen der Adapter effizienter arbeitet, wenn nur wenige Nachrichten auf einmal verarbeitet werden (z. B. beim Senden an einen Server, der gleichzeitige Verbindungen einschränkt), kann dieser Parameter außerdem auf einen Wert optimiert werden, der unter dem Standardwert liegt.

Bei dieser Analyse wird der Zähler "Hohe In-Process Nachrichtenanzahl" überprüft, um zu bestimmen, ob diese Art von Drosselung auftritt. Wenn ja, sollten Sie die Einstellung "In-Process messages per CPU" (In-Process-Nachrichten pro CPU) anpassen. Dieser Parameter wirkt sich nur auf die Einschränkung ausgehender Nachrichten aus. Geben Sie den Wert 0 in die Einstellung "In-Process messages per CPU" ein, um die Drosselung basierend auf der Anzahl der In-Process-Nachrichten pro CPU zu deaktivieren. Der Standardwert für die Einstellung "In-Process messages per CPU" ist 1.000. Beachten Sie, dass sich das Ändern dieses Werts auch auf die geringe Latenz von Nachrichten und/oder die Effizienz von BizTalk-Ressourcen auswirken kann.

Referenzen

• Ändern der Standardeinschränkungseinstellungen für den Host

• Leistungsindikatoren für die Hosteinschränkung

BizTalk– Analyse mit hoher Nachrichtenübermittlungsrate

Bei ausgehenden (übermittelten) Nachrichten drosselt BizTalk Server die Übermittlung von Nachrichten, wenn die Eingehende Rate für die Nachrichtenübermittlung für den Host instance die Ausgehende Rate der Nachrichtenübermittlung * den angegebenen Rate overdrive factor (Prozent) Wert überschreitet. Der Parameter rate overdrive factor (percent) kann im Dialogfeld Einstellungen für die Nachrichtenverarbeitungsdrosselung konfiguriert werden. Die ratenbasierte Drosselung für ausgehende Nachrichten wird in erster Linie dadurch erreicht, dass vor dem Entfernen der Nachrichten aus der In-Memory-Warteschlange eine Verzögerung ausgelöst wird und die Nachrichten zur Verarbeitung an den End Point Manager (EPM) oder die Orchestrierungs-Engine übermittelt werden. Es wird keine andere Aktion ausgeführt, um eine ratenbasierte Drosselung für ausgehende Nachrichten zu erreichen.

Die Einschränkung ausgehender Nachrichten kann dazu führen, dass die Nachrichtenübertragung verzögert wird und sich Daten in der Warteschlange im Arbeitsspeicher ansammeln. Dadurch können Threads zum Verarbeiten der Nachrichten in der Warteschlange blockiert werden, bis die Einschränkungsbedingung nicht mehr vorliegt. Wenn De-Queue-Threads blockiert werden, werden keine zusätzlichen Nachrichten aus dem MessageBox-Element für die ausgehende Übermittlung in die In-Memory-Warteschlange pullt.

Bei dieser Analyse wird der Wert 1 im Leistungsindikator "Hohe Nachrichtenübermittlungsrate" überprüft. Hohe Nachrichtenübermittlungsraten können durch eine hohe Verarbeitungskomplexität, langsame ausgehende Adapter oder einen vorübergehenden Mangel an Systemressourcen verursacht werden.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Implementieren der Hosteinschränkung mit BizTalk Server

• Ändern der Standardeinschränkungseinstellungen für den Host

BizTalk High Process Memory Analysis

Die Einstellung bizTalk Process Memory usage drosselt den Prozentsatz des verwendeten Arbeitsspeichers im Vergleich zur Summe der Größe des Arbeitssatzes und des gesamten verfügbaren virtuellen Arbeitsspeichers für den Prozess, wenn ein Wert von 1 bis 100 eingegeben wird. Standardmäßig ist die Einstellung für die Drosselung der Speicherauslastung für BizTalk-Prozesse 25. Wenn Sie einen Prozentwert eingeben, wird der Schwellenwert für den Prozessspeicher in regelmäßigen Abständen neu berechnet. Wenn der Benutzer einen Prozentwert angibt, wird dieser basierend auf dem verfügbaren Arbeitsspeicher und der aktuellen Verarbeitungsspeicherauslastung berechnet.

Bei dieser Analyse wird der Wert 1 im Leistungsindikator "Hoher Prozessarbeitsspeicher" überprüft. Wenn dies der Fall ist, versuchen Sie, die Ursache für die Arbeitsspeichervergrößerung mithilfe der Debugdiagnose zu ermitteln (siehe Verweise unter Analyse der Speicherleckerkennung). Beachten Sie, dass es normal ist, dass Prozesse während des Starts einen großen Teil des Arbeitsspeichers verbrauchen. Dies kann zunächst als Speicherverlust auftreten, aber ein echter Speicherverlust tritt auf, wenn ein Prozess nicht mehr benötigten Arbeitsspeicher freigibt, wodurch die Menge des verfügbaren Arbeitsspeichers im Laufe der Zeit verringert wird. Weitere Informationen zur generischen Analyse von Prozessspeicherverlusten in BizTalk finden Sie in der Referenz "Erfassen eines Speicherabbilds eines Prozesses, bei dem Arbeitsspeicher verloren geht" und/oder in der Analyse "Speicherleckerkennung" in PAL.

Eine hohe Prozessspeicherdrosselung kann auftreten, wenn der zu veröffentlichende Batch hohe Speicheranforderungen aufweist oder wenn zu viele Threads Nachrichten verarbeiten. Wenn das System anscheinend übermäßig gedrosselt ist, sollten Sie den Wert erhöhen, der dem Schwellenwert für die Verarbeitungsspeicherauslastung für den Host zugeordnet ist, und überprüfen Sie, ob der Host instance keinen Fehler "Nicht genügend Arbeitsspeicher" generiert. Wenn der Fehler "Nicht genügend Arbeitsspeicher" ausgelöst wird, indem der Schwellenwert für die Verarbeitungsspeicherauslastung erhöht wird, sollten Sie erwägen, die Werte für die Interne Nachrichtenwarteschlangengröße und die In-Process-Nachrichten pro CPU-Schwellenwert zu reduzieren. Diese Strategie ist besonders für Szenarien wichtig, in denen große Nachrichten verarbeitet werden. Darüber hinaus sollte dieser Wert für Szenarien mit großem Arbeitsspeicherbedarf pro Nachricht auf einen niedrigen Wert festgelegt werden. Das Festlegen eines niedrigen Werts drosselt frühzeitig und verhindert eine Speicherexplosion innerhalb des Prozesses.

Wenn auf Ihrem BizTalk-Server regelmäßig kein virtueller Arbeitsspeicher verfügbar ist, sollten Sie BizTalk Server 64-Bit in Betracht ziehen. Jeder Prozess auf 64-Bit-Servern kann bis zu 4 TB virtuellen Arbeitsspeichers im Vergleich zu 2 GB in 32-Bit adressieren. Im Allgemeinen werden 64-Bit-BizTalk und 64-Bit-SQL Server dringend empfohlen. Weitere Informationen finden Sie in der Referenz "BizTalk Server 64-Bit-Support".

Referenzen

• Implementieren der Hosteinschränkung mit BizTalk Server

• Ändern der Standardeinschränkungseinstellungen für den Host

• Aufzeichnen eines Speicherabbilds bei einem Prozess mit Speicherverlusten

• BizTalk Server 64-Bit-Unterstützung

BizTalk High System Memory Analysis

Der Schwellenwert für die Nutzungsdrosselung des physischen Arbeitsspeichers von BizTalk ist der Prozentsatz des Arbeitsspeicherverbrauchs im Vergleich zur Gesamtmenge des verfügbaren physischen Arbeitsspeichers, wenn ein Wert zwischen 1 und 100 eingegeben wird. Diese Einstellung kann auch die Gesamtmenge des verfügbaren physischen Arbeitsspeichers in Megabyte sein, wenn ein Wert größer als 100 eingegeben wird. Geben Sie zum Deaktivieren der auf der Auslastung des physikalischen Speichers basierenden Einschränkung den Wert 0 ein. Der Standardwert ist 0.

Bei dieser Analyse wird der Wert 1 im Leistungsindikator "Hoher Systemspeicher" überprüft. Da hiermit der gesamte Systemspeicher gemessen wird, kann eine Einschränkung ausgelöst werden, wenn Nicht-BizTalk Server-Prozesse übermäßig viel Systemspeicher beanspruchen. Daher besteht in diesem Fall der beste Ansatz darin, zu ermitteln, welche Prozesse den meisten physischen Arbeitsspeicher beanspruchen und/oder dem Server zusätzlichen physischen Arbeitsspeicher hinzufügen. Erwägen Sie außerdem, die Last zu reduzieren, indem Sie die Standardgröße des EPM-Threadpools und/oder die Größe der Adapterbatches reduzieren. Weitere Informationen finden Sie in der Analyse zur Erkennung von Speicherlecks in PAL.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Ändern der Standardeinschränkungseinstellungen für den Host

• Implementieren der Hosteinschränkung mit BizTalk Server

BizTalk–Analyse mit hoher Threadanzahl

"Threads pro CPU" ist die Gesamtanzahl der Threads im Hostprozess, einschließlich threads, die von Adaptern verwendet werden. Wenn dieser Schwellenwert überschritten wird, versuchen BizTalk Server, die Größe des EPM-Threadpools und des Nachrichten-Agent-Threadpools zu reduzieren. In Szenarien, in denen eine hohe Last zum Erstellen einer großen Anzahl von Threads führen kann, sollte die threadbasierte Einschränkung aktiviert werden. Dieser Parameter wirkt sich auf die Einschränkung eingehender und ausgehender Nachrichten aus. Threadbasierte Drosselung ist standardmäßig deaktiviert.

Hinweis

Der vom Benutzer angegebene Wert wird als Richtlinie verwendet, und der Host kann diesen Schwellenwert basierend auf den Speichernutzungsmustern und Threadanforderungen des Prozesses dynamisch selbst optimieren.

Bei dieser Analyse wird der Wert 1 im Zähler "Hohe Threadanzahl" überprüft. Passen Sie die verschiedenen Threadpoolgrößen an, um sicherzustellen, dass das System nicht sehr viele Threads erstellt. Diese Analyse kann mit der Analyse von Kontextwechseln pro Sekunde korreliert werden, um zu bestimmen, ob das Betriebssystem mit zu vielen Threads gesättigt ist, aber in den meisten Fällen führen hohe Threadanzahlen in der Back-End-Datenbank zu mehr Konflikten als auf dem BizTalk-Server. Weitere Informationen zum Ändern der Threadpoolgrößen finden Sie unter Ändern der Standardeinstellungen für die Hostdrosselung in Verweisen.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Implementieren der Hosteinschränkung mit BizTalk Server

• Ändern der Standardeinschränkungseinstellungen für den Host

• Konfigurationsparameter mit Auswirkung auf die Adapterleistung

• Threads, DB-Sitzungen und Drosselung

  BizTalk Inbound Latency AnalysisAverage Latenz in Millisekunden ab dem Empfang eines Dokuments vom Adapter durch die Messaging-Engine bis zum Zeitpunkt der Veröffentlichung im Meldungsfeld. Die Verringerung der Latenz ist für einige Benutzer von BizTalk wichtig, daher ist die Nachverfolgung der Zeit, die Dokumente im eingehenden Adapter verbringen, wichtig.

  Hier sehen Sie ein Diagramm, das zeigt, wie die Latenz gemessen wird.

1	2	3	4	5	6
Der Adapter empfängt eine Nachricht und sendet sie an das Modul. Die Arbeit erfolgt im Adapter, bevor die Nachricht an das Modul übergeben wird, das in diesen Perf-Leistungsindikatoren nicht erfasst wurde.	Engine empfängt Eine Nachricht vom Adapter, führt Empfangspipeline, Zuordnung, Abonnementauswertung und Persistenznachricht in der Datenbank aus.	Orchestrierung oder Solicit-Response Port wird ausgeführt und eine Antwortmeldung generiert.	Die Antwortnachricht wird in der Messaging-Engine dequeuiert, führen Sie die Sendepipeline aus, ordnen Sie zu.	Messaging-Engine gibt Antwortnachricht an den Adapter.	Der Adapter informiert, dass die Enginemeldung erledigt ist.
	I
	RR	RR	RR
			O	O	O
				OA	OA

I = Eingehende Latenz

RR = Anforderungsantwortlatenz

O = Ausgehende Latenz

OA = Ausgehende Adapterlatenz

Bei einer Umgebung mit geringer Latenz wird bei dieser Analyse überprüft, ob das Dokument mehr als 5 Sekunden im eingehenden Adapter verbracht hat. Dies kann auf eine Verarbeitungsverzögerung beim Transport von Nachrichten über eingehende Adapter in diesem Host instance hinweisen. Wenn in diesem Host instance mehrere eingehende Adapter vorhanden sind, sollten Sie diese in ihre eigenen Hosts aufteilen, um zu ermitteln, welcher eingehende Adapter eine hohe Latenz aufweist.

Referenzen

• Optimieren der Datenbankleistung

• Messaging vom Typ 'Anforderungsantwort'

• Erkennen von Engpässen auf der BizTalk-Ebene

Analyse der BizTalk-Drosselung des Nachrichtenübermittlungsstatus

Der Status der BizTalk-Nachrichtenübermittlungsdrosselung ist einer der primären Indikatoren für die Drosselung. Es ist ein Flag, das angibt, ob das System die Nachrichtenübermittlung drosselt (was sich auf die XLANG-Nachrichtenverarbeitung und ausgehende Transporte auswirkt). Die Einschränkungsbedingung wird durch den numerischen Wert des Zählers angegeben. Hier finden Sie eine Liste der Werte und ihrer jeweiligen Bedeutung:

Einschränkungsbedingung	BESCHREIBUNG
0	Keine Einschränkung
1	Einschränkung aufgrund einer ungleichen Rate der Nachrichtenübermittlung (Eingangsrate liegt über der Ausgangsrate)
3	Einschränkung wegen einer zu hohen Anzahl in Verarbeitung befindlicher Nachrichten
4	Einschränkung infolge einer zu hohen Belegung des Prozessspeichers
5	Einschränkung wegen einer zu hohen Belegung des Systemspeichers
9	Einschränkung aufgrund einer zu hohen Anzahl von Threads
10	Einschränkung aufgrund einer Außerkraftsetzung durch den Benutzer bei der Übermittlung

Diese Analyse überprüft jeden dieser Werte und enthält eine spezifische Warnung für jeden dieser Werte.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Implementieren der Hosteinschränkung mit BizTalk Server

Analyse von BizTalk MessageBox-Datenbankverbindungsfehlern

Dieser Leistungsindikator ist die Anzahl der versuchten Datenbankverbindungen, die seit dem Start des Hosts instance fehlgeschlagen sind. Wenn der SQL Server Dienst, der die BizTalk-Datenbanken hostt, aus irgendeinem Grund nicht verfügbar ist, überträgt der Datenbankcluster Ressourcen vom aktiven Computer auf den passiven Computer. Während dieses Failoverprozesses treten bei den BizTalk Server-Dienstinstanzen Datenbankverbindungsfehler auf. Die Instanzen werden automatisch neu gestartet, um die Datenbankverbindung wiederherzustellen. Der funktionierende Datenbankcomputer (der zuvor passive Computer) beginnt mit der Verarbeitung der Datenbankverbindungen nach Übernahme der Ressourcen während des Failovers.

DBNetLib-Fehler (Datenbanknetzwerkbibliothek) treten auf, wenn die BizTalk Server Runtime weder mit der MessageBox noch mit verwaltungsbasierten Datenbanken kommunizieren kann. Wenn dies der Fall ist, wird die BizTalk Server Runtime instance, die die Ausnahme abfangen, heruntergefahren und dann jede Minute mit einem Takt ausgeführt, um zu überprüfen, ob die Datenbank verfügbar ist. Weitere Informationen zu diesem Thema finden Sie im Abschnitt verweise.

Wenn ein Client eine TCP/IP-Socketverbindung mit einem Server initiiert, stellt er in der Regel eine Verbindung mit einem bestimmten Port auf dem Server her und fordert den Server auf, dem Client über einen kurzlebigen ("ephemeral") TCP- oder UDP-Port zu antworten. Unter Windows Server 2003 und Windows XP liegt der Standardbereich von kurzlebigen Ports, die von Clientanwendungen verwendet werden, zwischen 1025 und 5000. Unter bestimmten Bedingungen ist es möglich, dass die verfügbaren Ports im Standardbereich erschöpft sind. Weitere Informationen zu diesem Thema finden Sie im Abschnitt verweise.

Bei dieser Analyse wird überprüft, ob Datenbankverbindungsfehler auftreten. Datenbankverbindungsfehler sind kritisch, da BizTalk ohne die Datenbank nicht funktionieren kann. Wenn die Ursache des Datenbankverbindungsfehlers unbekannt ist, berücksichtigen Sie die unten aufgeführten Verweise und/oder kontakt Microsoft-Support, um die Art des Konnektivitätsfehlers zu ermitteln.

Referenzen

• Ausskalierte Datenbanken

• Vermeiden von DBNETLIB-Ausnahmen

• Vermeiden des Verbrauchs von TCP/IP-Ports

BizTalk Messaging– Veröffentlichungsdrosselungszustandsanalyse

Der Status der Veröffentlichung von BizTalk-Nachrichten ist einer der primären Indikatoren für die Drosselung. Es ist ein Flag, das angibt, ob das System die Nachrichtenveröffentlichung drosselt (was sich auf die XLANG-Nachrichtenverarbeitung und eingehende Transporte auswirkt). Die Einschränkungsbedingung wird durch den numerischen Wert des Zählers angegeben. Hier finden Sie eine Liste der Werte und ihrer jeweiligen Bedeutung:

Einschränkungsbedingung	BESCHREIBUNG
0	Keine Einschränkung
2	Einschränkung aufgrund einer ungleichen Rate der Nachrichtenveröffentlichung (Eingangsrate liegt über der Ausgangsrate)
4	Einschränkung infolge einer zu hohen Belegung des Prozessspeichers
5	Einschränkung wegen einer zu hohen Belegung des Systemspeichers
6	Einschränkung aufgrund zu großen Wachstums der Datenbank
8	Einschränkung aufgrund einer zu hohen Anzahl von Sitzungen
9	Einschränkung aufgrund einer zu hohen Anzahl von Threads
11	Einschränkung infolge einer Außerkraftsetzung durch den Benutzer bei der Veröffentlichung

Diese Analyse überprüft jeden dieser Werte und enthält eine spezifische Warnung für jeden dieser Werte.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Implementieren der Hosteinschränkung mit BizTalk Server

BizTalk-Orchestrierungen, die sich im Arbeitsspeicher befinden

Die Anzahl der Orchestrierungsinstanzen, die derzeit von der Hostinstanz gehostet werden. Während Spitzen oder Bursts von Orchestrierungen, die sich im Arbeitsspeicher befinden, als normal betrachtet werden können, könnte ein zunehmender Trend auf eine "Anhäufung" von Orchestrierungen im Arbeitsspeicher hindeuten. Ein zunehmender Trend kann im Laufe der Zeit auftreten, wenn BizTalk Nachrichten/Orchestrierungsinstanzen nicht dehydrieren kann. Versuchen Sie, diesen Indikator mit "XLANG/s Orchestrations(?) zu korrelieren. \Dehydrierbare Orchestrierungen", wobei das Fragezeichen (?) der gleiche Zähler instance wie dieser Zähler ist.

Wenn eine hohe Anzahl von Orchestrierungen im Arbeitsspeicher vorhanden ist und eine geringe Anzahl von Orchestrierungen dehydrierbar ist, befinden sich Ihre Orchestrierungen wahrscheinlich im Leerlauf des Arbeitsspeichers und können zu einem Speicherverlust führen. Verwenden Sie diese Analyse in Korrelation mit "\XLANG/s Orchestrierungen(*)\Idle Orchestrations", falls vorhanden. Ein zunehmender Trend bei BizTalk-Idle-Orchestrierungen ist ein besserer Indikator für Speicherverluste aufgrund der Unfähigkeit, Orchestrierungsinstanzen zu dehydrieren.

Bei dieser Analyse wird überprüft, ob die Orchestrierungen, die sich im Arbeitsspeicher befinden, zunehmend trendig sind und ob mehr als 50 % der im Arbeitsspeicher ansässigen Orchestrierungen nicht dehydrierbar sind.

Referenzen

• Leistungsindikatoren für Orchestrierungs-Engine

• Pausieren und Aktivieren einer Orchestrierung

Analyse privater BizTalk-Bytes

Dies ist die Megabyte des zugeordneten privaten Arbeitsspeichers für den Host instance und vergleichbar mit dem Leistungsindikator "\Process(*)\Private Bytes". Private Bytes sind die aktuelle Größe des Arbeitsspeichers, den ein Prozess zugewiesen hat und der nicht für andere Prozesse freigegeben werden kann. Diese Analyse bestimmt, ob eine der Hostinstanzen eine große Größe des Systemspeichers verbraucht und ob der Host instance den Arbeitsspeicherverbrauch im Laufe der Zeit zunimmt. Ein Host instance große Teile des Arbeitsspeichers verbraucht, ist in Ordnung, solange er den Arbeitsspeicher an das System zurückgibt. Suchen Sie im Diagramm nach zunehmenden Trends. Ein zunehmender Trend über einen langen Zeitraum könnte auf einen Speicherverlust hinweisen.

Bei dieser Analyse wird überprüft, ob sich der Trend um 10 MB pro Stunde erhöht. Verwenden Sie diese Analyse in Korrelation mit der Analyse des verfügbaren Arbeitsspeichers und der Analyse des Speicherverlusts. Beachten Sie außerdem, dass neu gestartete Hostinstanzen zunächst als Speicherverlust auftreten, wenn es sich lediglich um ein normales Startverhalten handelt. Ein Speicherverlust liegt vor, wenn ein Prozess weiterhin Arbeitsspeicher beansprucht und über einen langen Zeitraum keinen Arbeitsspeicher freigibt. Wenn Sie einen Speicherverlust vermuten, lesen Sie den artikel "Arbeitsspeicherwachstum in BizTalk Messaging", auf den unten verwiesen wird. Installieren Sie andernfalls das Debugdiagnosetool, und verwenden Sie es. Weitere Informationen zum Debugdiagnosetool finden Sie im Abschnitt verweise.

Referenzen

• Debugdiagnosetool

• Arbeitsspeicherzuwachs in BizTalk Messaging

Analyse virtueller BizTalk-Bytes

Dies sind die Megabyte, die für den virtuellen Arbeitsspeicher für den Host instance reserviert sind. Diese Analyse bestimmt, ob eine der Hostinstanzen eine große Menge des Systemspeichers verbraucht und ob der Host instance im Laufe der Zeit den Arbeitsspeicherverbrauch erhöht. Ein Host instance große Teile des Arbeitsspeichers verbraucht, ist in Ordnung, solange er den Arbeitsspeicher an das System zurückgibt. Suchen Sie im Diagramm nach zunehmenden Trends. Ein zunehmender Trend über einen langen Zeitraum könnte auf einen Speicherverlust hinweisen.

Bei dieser Analyse wird überprüft, ob sich der Trend in virtuellen Bytes um 10 MB pro Stunde erhöht. Verwenden Sie diese Analyse in Korrelation mit der Analyse des verfügbaren Arbeitsspeichers und der Analyse des Speicherverlusts. Beachten Sie außerdem, dass neu gestartete Hostinstanzen zunächst als Speicherverlust auftreten, wenn es sich lediglich um ein normales Startverhalten handelt. Ein Speicherverlust liegt vor, wenn ein Prozess weiterhin Arbeitsspeicher beansprucht und über einen langen Zeitraum keinen Arbeitsspeicher freigibt. Wenn Sie einen Speicherverlust vermuten, lesen Sie den folgenden Artikel "Arbeitsspeicherwachstum in BizTalk Messaging". Installieren Sie andernfalls das Debugdiagnosetool, und verwenden Sie es. Weitere Informationen zum Debugdiagnosetool finden Sie im Abschnitt verweise.

Referenzen

• Debugdiagnosetool

• Arbeitsspeicherzuwachs in BizTalk Messaging

Analyse der Sitzungsdrosselung der BizTalk-Nachrichten-Agent-Datenbank

Dies ist die Anzahl der offenen Datenbankverbindungen für messageBox im Vergleich zu der jeweiligen BizTalk-Einschränkungseinstellung. "Datenbankverbindung pro CPU" ist die maximale Anzahl gleichzeitiger Datenbanksitzungen (pro CPU), die vor Beginn der Drosselung zulässig ist. Datenbanksitzungen im Leerlauf im Allgemeinen Sitzungspool pro Host werden in diesen Wert nicht einbezogen. Für diesen Parameter ist ausschließlich die Anzahl der Sitzungen relevant, die tatsächlich von der Hostinstanz genutzt werden. Diese Option ist standardmäßig deaktiviert und sollte nur aktiviert werden, wenn der Datenbankserver einen Engpass im BizTalk Server-System bildet. Sie können die Anzahl der aktiven Datenbankverbindungen mithilfe des Leistungsindikators der Datenbanksitzung unter der Kategorie BizTalk:Message Agent-Leistungsobjekt überwachen. Dieser Parameter wirkt sich nur auf die Einschränkung ausgehender Nachrichten aus. Geben Sie zum Deaktivieren der auf der Anzahl der Datenbanksitzungen basierenden Einschränkung den Wert 0 ein. Der Standardwert ist 0.

Der MaxWorkerThreads-Registrierungsschlüssel hat Einfluss auf die Anzahl der für BizTalk verfügbaren Threads und kann hilfreich sein, wenn die meisten BizTalk-Threads mit Datenbankverbindungen beschäftigt sind. Bei dieser Analyse wird überprüft, ob die Anzahl der geöffneten Datenbankverbindungen für das MessageBox-Element größer als 80 Prozent der Einstellung datenbanksitzungsdrosselung ist, was angibt, dass eine Einschränkung wahrscheinlich ist.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Konfigurationsparameter mit Auswirkung auf die Adapterleistung

• Threads, DB-Sitzungen und Drosselung

Schwellenwertanalyse der BizTalk-Nachrichten-Agent-Datenbank zur Sitzungsdrosselung

Dies ist der aktuelle Schwellenwert für die Anzahl der geöffneten Datenbankverbindungen für messageBox. "Datenbankverbindung pro CPU" ist die maximale Anzahl gleichzeitiger Datenbanksitzungen (pro CPU), die vor Beginn der Drosselung zulässig ist. Datenbanksitzungen im Leerlauf im Allgemeinen Sitzungspool pro Host werden in diesen Wert nicht einbezogen. Für diesen Parameter ist ausschließlich die Anzahl der Sitzungen relevant, die tatsächlich von der Hostinstanz genutzt werden. Diese Option ist standardmäßig deaktiviert und sollte nur aktiviert werden, wenn der Datenbankserver einen Engpass im BizTalk Server-System bildet. Sie können die Anzahl der aktiven Datenbankverbindungen mithilfe des Leistungsindikators der Datenbanksitzung unter der Kategorie BizTalk:Message Agent-Leistungsobjekt überwachen. Dieser Parameter wirkt sich nur auf die Einschränkung ausgehender Nachrichten aus. Geben Sie zum Deaktivieren der auf der Anzahl der Datenbanksitzungen basierenden Einschränkung den Wert 0 ein. Der Standardwert ist 0.

Der MaxWorkerThreads-Registrierungsschlüssel hat Einfluss auf die Anzahl der für BizTalk verfügbaren Threads und kann hilfreich sein, wenn die meisten BizTalk-Threads mit Datenbankverbindungen beschäftigt sind. Bei dieser Analyse wird dieser Wert überprüft, um festzustellen, ob er von seiner Standardeinstellung abgeändert wurde. Standardmäßig ist diese Einstellung 0. Dies bedeutet, dass die Einschränkung für Datenbanksitzungen deaktiviert ist.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Konfigurationsparameter mit Auswirkung auf die Adapterleistung

• Threads, DB-Sitzungen und Drosselung

BizTalk-Nachrichten-Agent In-Process-Analyse zur Einschränkung der Anzahl von Nachrichten

Dies ist die Anzahl gleichzeitiger Nachrichten, die von der Dienstklasse verarbeitet werden. Die Einstellung "In-process messages per CPU" in the Host Drosselling Settings (Host Drosselling Settings) ist die maximale Anzahl von Nachrichten, die an den Endpunkt-Manager (EPM) oder XLANG übermittelt wurden, die nicht verarbeitet wurden. Dies schließt nicht die Nachrichten ein, die aus der Datenbank abgerufen wurden, aber weiterhin auf die Übermittlung in der In-Memory-Warteschlange warten. Sie können die Anzahl der In-Process-Nachrichten überwachen, indem Sie den Leistungsindikator Für die Anzahl von In-Process-Nachrichten unter der Leistungsobjektkategorie BizTalk:Message Agent verwenden. Dieser Parameter kann vom Einschränkungsmechanismus als Hinweis genutzt werden, der bei der Bestimmung von Einschränkungsbedingungen berücksichtigt wird. Der eigentliche Schwellenwert unterliegt der Selbstoptimierung. Sie können den tatsächlichen Schwellenwert überprüfen, indem Sie den Leistungsindikator Anzahl in Verarbeitung befindlicher Nachrichten überwachen.

Bei Szenarien mit großen Nachrichten (bei denen entweder die durchschnittliche Nachrichtengröße hoch ist oder die Verarbeitung von Nachrichten eine große Anzahl von Nachrichten erfordert), kann dieser Parameter auf einen kleineren Wert festgelegt werden. Ein Szenario mit großen Nachrichten wird angezeigt, wenn die speicherbasierte Drosselung zu häufig auftritt und der Arbeitsspeicherschwellenwert automatisch auf einen erheblich niedrigen Wert angepasst wird. Ein solches Verhalten zeigt an, dass die Zahl der vom ausgehenden Transport gleichzeitig verarbeiteten Nachrichten reduziert werden sollte, um eine zu hohe Speicherauslastung zu vermeiden. In Szenarien, in denen der Adapter effizienter arbeitet, wenn nur wenige Nachrichten auf einmal verarbeitet werden (z. B. beim Senden an einen Server, der gleichzeitige Verbindungen einschränkt), kann dieser Parameter außerdem auf einen Wert optimiert werden, der unter dem Standardwert liegt. Bei dieser Analyse wird der Leistungsindikator "Hohe In-Process Nachrichtenanzahl" überprüft, um zu ermitteln, ob er mehr als 80 Prozent seiner Einschränkungseinstellung unter demselben Namen aufweist, was darauf hindeutet, dass eine Einschränkung wahrscheinlich ist.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Ändern der Standardeinschränkungseinstellungen für den Host

BizTalk:Nachrichten-Agent In-Process Message Count Drosselung Schwellenwertanalyse

Dies ist der aktuelle Schwellenwert für die Anzahl gleichzeitiger Nachrichten, die von der Dienstklasse verarbeitet werden. Die Einstellung "In-process messages per CPU" in the Host Drosselling Settings (Host Drosselling Settings) ist die maximale Anzahl von Nachrichten, die an den Endpunkt-Manager (EPM) oder XLANG übermittelt wurden, die nicht verarbeitet wurden. Dies schließt nicht die Nachrichten ein, die aus der Datenbank abgerufen wurden, aber weiterhin auf die Übermittlung in der In-Memory-Warteschlange warten. Sie können die Anzahl der In-Process-Nachrichten überwachen, indem Sie den Leistungsindikator Für die Anzahl von In-Process-Nachrichten unter der Leistungsobjektkategorie BizTalk:Message Agent verwenden. Dieser Parameter kann vom Einschränkungsmechanismus als Hinweis genutzt werden, der bei der Bestimmung von Einschränkungsbedingungen berücksichtigt wird. Der eigentliche Schwellenwert unterliegt der Selbstoptimierung. Sie können den tatsächlichen Schwellenwert überprüfen, indem Sie den Leistungsindikator Anzahl in Verarbeitung befindlicher Nachrichten überwachen.

Bei Szenarien mit großen Nachrichten (bei denen entweder die durchschnittliche Nachrichtengröße hoch ist oder die Verarbeitung von Nachrichten eine große Anzahl von Nachrichten erfordert), kann dieser Parameter auf einen kleineren Wert festgelegt werden. Ein Szenario mit großen Nachrichten wird angezeigt, wenn die speicherbasierte Drosselung zu häufig auftritt und der Arbeitsspeicherschwellenwert automatisch auf einen erheblich niedrigen Wert angepasst wird. Ein solches Verhalten zeigt an, dass die Zahl der vom ausgehenden Transport gleichzeitig verarbeiteten Nachrichten reduziert werden sollte, um eine zu hohe Speicherauslastung zu vermeiden. In Szenarien, in denen der Adapter effizienter arbeitet, wenn nur wenige Nachrichten auf einmal verarbeitet werden (z. B. beim Senden an einen Server, der gleichzeitige Verbindungen einschränkt), kann dieser Parameter außerdem auf einen Wert optimiert werden, der unter dem Standardwert liegt. Bei dieser Analyse wird der Schwellenwert für hohe In-Process Nachrichtenanzahl auf einen Nicht-Standardwert überprüft.

Referenzen

• Leistungsindikatoren für die Hosteinschränkung

• Ändern der Standardeinschränkungseinstellungen für den Host

BizTalk Message Agent Process Memory Usage (MB) Drosselungsanalyse

Dies ist die Arbeitsspeicherauslastung des aktuellen Prozesses (MB). Die Speicherdrosselung des BizTalk-Prozesses kann auftreten, wenn der zu veröffentlichende Batch hohe Speicheranforderungen aufweist oder wenn zu viele Threads Nachrichten verarbeiten. Wenn das System eine Überdrosselung zu haben scheint, sollten Sie den Wert erhöhen, der dem Schwellenwert für die Verarbeitungsspeicherauslastung für den Host zugeordnet ist, und überprüfen Sie, ob der Host instance keinen Fehler "Nicht arbeitsspeicherfrei" generiert. Wenn durch Erhöhen des Schwellenwerts für die Verarbeitungsspeicherauslastung ein Fehler "Nicht genügend Arbeitsspeicher" ausgelöst wird, sollten Sie die Werte für die Interne Nachrichtenwarteschlangengröße und die In-Process-Nachrichten pro CPU-Schwellenwerte reduzieren. Diese Strategie ist besonders für Szenarien wichtig, in denen große Nachrichten verarbeitet werden.

Wenn auf Ihrem BizTalk-Server regelmäßig der virtuelle Arbeitsspeicher ausgeht, sollten Sie BizTalk Server 64-Bit in Betracht ziehen. Jeder Prozess auf 64-Bit-Servern kann bis zu 4 TB virtuellen Arbeitsspeicher im Vergleich zu 2 GB in 32-Bit adressieren. Im Allgemeinen werden 64-Bit-BizTalk und 64-Bit-SQL Server dringend empfohlen. Weitere Informationen finden Sie in der Referenz "BizTalk Server 64-Bit-Unterstützung". Bei dieser Analyse wird überprüft, ob die Arbeitsspeicherauslastung des Prozesses größer als 80 Prozent des Drosselungsschwellenwerts desselben Namens ist. Standardmäßig beträgt die Einstellung "BizTalk Process Memory Usage drosselling" 25 Prozent des für den Prozess verfügbaren virtuellen Arbeitsspeichers. Der Schalter /3GB hat keine Auswirkungen auf diese Einstellung.

Referenzen

• Implementieren der Hosteinschränkung mit BizTalk Server

• Ändern der Standardeinschränkungseinstellungen für den Host

• Aufzeichnen eines Speicherabbilds bei einem Prozess mit Speicherverlusten

• BizTalk Server 64-Bit-Unterstützung

BizTalk:Message Agent Process Memory Usage (MB) Drosselung Schwellenwertanalyse

Dies ist der aktuelle Schwellenwert für die Arbeitsspeicherauslastung des aktuellen Prozesses (MB). Der Schwellenwert kann dynamisch angepasst werden, abhängig von der tatsächlichen Menge an Arbeitsspeicher, die für diesen Prozess verfügbar ist, und seinem Speicherverbrauchsmuster. Die Speicherdrosselung des BizTalk-Prozesses kann auftreten, wenn der zu veröffentlichende Batch hohe Speicheranforderungen aufweist oder wenn zu viele Threads Nachrichten verarbeiten. Wenn das System eine Überdrosselung zu haben scheint, sollten Sie den Wert erhöhen, der dem Schwellenwert für die Verarbeitungsspeicherauslastung für den Host zugeordnet ist, und überprüfen Sie, ob der Host instance keinen Fehler "Nicht arbeitsspeicherfrei" generiert. Wenn durch Erhöhen des Schwellenwerts für die Verarbeitungsspeicherauslastung ein Fehler "Nicht genügend Arbeitsspeicher" ausgelöst wird, sollten Sie die Werte für die Interne Nachrichtenwarteschlangengröße und die In-Process-Nachrichten pro CPU-Schwellenwerte reduzieren. Diese Strategie ist besonders für Szenarien wichtig, in denen große Nachrichten verarbeitet werden.

Wenn auf Ihrem BizTalk-Server regelmäßig der virtuelle Arbeitsspeicher ausgeht, sollten Sie BizTalk Server 64-Bit in Betracht ziehen. Jeder Prozess auf 64-Bit-Servern kann bis zu 4 TB virtuellen Arbeitsspeicher im Vergleich zu 2 GB in 32-Bit adressieren. Im Allgemeinen werden 64-Bit-BizTalk und 64-Bit-SQL Server dringend empfohlen. Weitere Informationen finden Sie in der Referenz "BizTalk Server 64-Bit-Unterstützung". Bei dieser Analyse wird überprüft, ob die Arbeitsspeicherdrosselung verarbeiten auf einen Nicht-Standardwert festgelegt ist.

Referenzen

• Implementieren der Hosteinschränkung mit BizTalk Server

• Ändern der Standardeinschränkungseinstellungen für den Host

• Aufzeichnen eines Speicherabbilds bei einem Prozess mit Speicherverlusten

• BizTalk Server 64-Bit-Unterstützung