Erkennen von Engpässen auf der BizTalk-Ebene

Artikel
05/04/2023

Die BizTalk-Ebene gliedert sich in die folgenden Funktionsbereiche:

Empfangen
Verarbeitung
Übertragung
Nachverfolgung
Sonstiges

Wenn die Systemressourcen (CPU, Arbeitsspeicher und Festplatte) für diese Bereiche überlastet sind, rüsten Sie den Server durch zentrales Skalieren auf. Wenn die Systemressourcen nicht überlastet sind, führen Sie die in diesem Abschnitt beschriebenen Schritte aus.

Engpässe am Empfangsspeicherort

Wenn die Anzahl der Nachrichten am Empfangsspeicherort zunimmt (der Dateiempfangsordner wird größer oder die ausgehende Warteschlange wird nicht schnell genug geleert), ist dies ein Zeichen dafür, dass das System Daten aufgrund interner Einschränkung nicht mehr schnell genug aufnehmen kann, um mit der eingehenden Last Schritt zu halten (BizTalk reduziert die Empfangsrate, wenn die Abonnenten nicht in der Lage sind, Daten schnell genug zu verarbeiten, sodass sich in den Datenbanktabellen ein Rückstand aufbaut). Falls der Engpass durch Beschränkungen der Hardware verursacht wird, versuchen Sie eine zentrale Skalierung. Es ist auch möglich, dezentral zu skalieren. Dazu wird dem Host, der dem Empfangshandler zugeordnet ist, eine Hostinstanz (Server) hinzugefügt. Überwachen Sie die Ressourcennutzung auf dem System mit dem Systemmonitor. Es muss in jedem Fall festgestellt werden, ob der Engpass durch den externen Empfangsspeicherort verursacht wird. Beispielsweise ist die Remotedateifreigabe aufgrund hoher Datenträger-E/A überlastet, oder der Server, der die ausgehende Remotewarteschlange hostet, ist nicht gesättigt, oder der Client, durch den die HTTP/SOAP-Last generiert wird, verfügt über genügend Threads.

Verarbeitungsengpässe

Wenn sich der Wert für Hostwarteschlange - Länge (siehe folgende Tabelle der Leistungsindikatoren) erhöht, werden die Orchestrierungen nicht schnell genug ausgeführt. Mögliche Gründe hierfür sind Speicherkonflikte oder CPU-Überlastung.

Wenn die Orchestrierungsserver den Engpass verursachen, ermitteln Sie die Quelle mit dem Systemmonitor.

Wenn der Server CPU-abhängig ist, ziehen Sie die folgenden Schritte in Betracht:

Bei einem komplexen Workflow sollten Sie die Orchestrierung in mehrere kleinere Orchestrierungen aufteilen.

Hinweis

Das Aufteilen einer Orchestrierung in mehrere Workflows kann zusätzliche Wartezeit nach sich ziehen und die Komplexität erhöhen.
Wenn komplexe Zuordnungen verwendet werden, überlegen Sie, ob sie zu den Empfangs-/Sendeports verschoben werden können (überprüfen Sie, welche Ports über zusätzliche Bandbreite verfügen).
Ziehen Sie ein zentrales Skalieren der Hardware in Betracht, oder verwenden Sie eine dezentrale Skalierung, und konfigurieren Sie einen zusätzlichen Verarbeitungsserver.

Übertragungsengpässe

Wenn die Ressourcen (z. B. Festplatte, Arbeitsspeicher, CPU) des übertragenden Servers überlastet sind, ziehen Sie eine zentrale Skalierung des Servers in Betracht, oder führen Sie eine dezentrale Skalierung auf zusätzliche sendende Hostserver aus. Die Sendeebene kann zum Engpass werden, wenn das (für BizTalk externe) Ziel die Daten nicht schnell genug empfangen kann. Dadurch sammeln sich Nachrichten in der MessageBox-Datenbank (Anwendung SendHostQ) an.

Wenn sich alle Endpunkte innerhalb des Bereichs der Topologie befinden, sollten Sie die Ursache am Ziel isolieren. Ist beispielsweise der HTTP/SOAP-Speicherort optimal für den Empfang der Last konfiguriert oder kann er dezentral skaliert werden? Nimmt die Datenmenge am Ziel zu, da von BizTalk eine zu große Zahl ausgehender Nachrichten übermittelt wird? Falls ja, sollten Sie eventuell einen Wartungsplan einrichten, um die Zielnachrichten zu archivieren und zu löschen. Eine große Anzahl von Dateien in einem Zielordner kann beispielsweise die Fähigkeit des BizTalk-Diensts, Daten an den Datenträger zu übergeben, stark beeinträchtigen.

Überwachungsengpässe

Die Instanz des überwachenden Hosts hat die Aufgabe, BAM- sowie überwachte Nachrichtenereignis- und Dienstinstanzdaten aus der MessageBox-Datenbank (TrackingData-Tabelle) in die BizTalkDTADb- und/oder BAMPrimaryImport-Datenbanktabellen zu verschieben. Wenn mehrere MessageBox-Datenbanken konfiguriert werden, verwendet die Instanz des überwachenden Hosts vier Threads pro MessageBox.

Möglicherweise wird diese Hostinstanz CPU-abhängig. Ist dies der Fall, ziehen Sie ein zentrales Skalieren des Servers in Betracht, oder verwenden Sie eine dezentrale Skalierung, und konfigurieren Sie einen zusätzlichen Server mit aktivierter Hostüberwachung. Die Hostinstanzen verteilen die Last automatisch gleichmäßig auf die konfigurierten MessageBoxes.

Wenn die TrackingData-Tabelle in der MessageBox-Datenbank in Rückstand gerät, liegt dies in der Regel daran, dass die Datenwartungsaufträge in der BizTalkDTADb- und/oder der BAMPrimaryImport-Datenbank nicht wie konfiguriert ausgeführt werden und zu einer Vergrößerung der BizTalkDTADb- und/oder BAMPrimaryImport-Datenbank führen. Wenn diese Datenbanken zu groß geworden sind, kann darunter die Fähigkeit des überwachenden Hosts leiden, Daten in diese Tabellen einzufügen, sodass sich die überwachten Daten in den MessageBox-Datenbanktabellen ansammeln. Das Wachstum der Tabelle MessageBox-TrackingData> führt dazu, dass die Drosselung ausgelöst wird.

Sonstiges

Konfigurieren Sie die Bereitstellungstopologie so, dass in dedizierten isolierten Hostinstanzen unterschiedliche Funktionen ausgeführt werden. Auf diese Weise erhält jede Hostinstanz ihre eigenen Ressourcen (auf einem 32-Bit-System einen 2 GB großen virtuellen Speicheradressraum, Handles, Threads). Wenn die Serverleistung (genügend CPU-Reserven und Arbeitsspeicher) für mehrere Hostinstanzen ausreicht, können diese so konfiguriert werden, dass sie auf dem gleichen Computer ausgeführt werden. Andernfalls ist auch ohne weiteres eine dezentrale Skalierung möglich, wobei die Funktionen auf dedizierte Server verschoben werden. Das Ausführen der gleichen Funktionen auf mehreren Servern führt zudem zu einer hoch verfügbaren Konfiguration.

Leistungsindikatoren für das BizTalk-System

Object	Instanz	Leistungsindikator	Überwachungszweck
Prozessor	_Total	% Prozessorzeit	Ressourcenkonflikte
Prozess	BTSNTSvc	Virtuelle Bytes	Speicherverlust/-überlastung
Prozess	BTSNTSvc	Private Bytes	Speicherverlust/-überlastung
Prozess	BTSNTSvc	Anzahl von Handles	Ressourcenkonflikte
Prozess	BTSNTSvc	Threadanzahl	Ressourcenkonflikte
Physikalischer Datenträger	_Total	% Leerlaufzeit	Ressourcenkonflikte
Physikalischer Datenträger	_Total	Aktuelle Warteschlangenlänge	Ressourcenkonflikte

CPU-Konflikte

Wenn der Prozessor überlastet ist, sollten Sie die Anwendung fragmentieren und den Empfang vom Sendemodul und der Orchestrierung trennen. Dazu erstellen Sie separate Hosts, ordnen diese bestimmten Funktionen zu (Empfangen/Senden/Orchestrierungen/Überwachung) und fügen diesen separaten Hosts dedizierte Server hinzu. Die Orchestrierungsfunktion gilt im Allgemeinen als CPU-intensiv. Wird das System daher so konfiguriert, dass die Orchestrierungen auf einem separaten dedizierten Server ausgeführt werden, lässt sich der Systemdurchsatz insgesamt verbessern.

Wenn mehrere Orchestrierungen bereitgestellt werden, können sie auf verschiedenen dedizierten Orchestrierungshosts eingetragen werden. Werden verschiedene physische Server den dedizierten Orchestrierungshosts zugeordnet, werden die verschiedenen Orchestrierungen isoliert und konkurrieren daher nicht um freigegebene Ressourcen im gleichen physischen Adressraum oder auf dem gleichen Server.

Nichtzugriff auf den Arbeitsspeicher

Szenarien mit hohem Durchsatz können zu einer stärkeren Beanspruchung des Arbeitsspeichers führen. Da ein 32-Bit-Prozess nicht beliebig viel Arbeitsspeicher beanspruchen kann, empfiehlt es sich, die Empfangs-/Verarbeitungs-/Sendefunktionen auf separate Hostinstanzen aufzuteilen, damit jeder Host seinen eigenen 2-GB-Adressraum erhält. Werden darüber hinaus mehrere Hostinstanzen auf dem gleichen physikalischen Server ausgeführt, ist eine Aufrüstung auf 4/8 GB Arbeitsspeicher sinnvoll, damit Daten nicht vom Arbeitsspeicher auf die Festplatte ausgelagert werden müssen. Orchestrierungen mit langer Ausführungsdauer können den zugeordneten Speicher länger halten, was zu einer Speicheraufblähung und Drosselung führt. Große Nachrichten können auch zu einem hohen Arbeitsspeicherverbrauch führen.

Es ist möglich, dieses Speicheraufblähungsproblem zu beheben, wenn große Nachrichten verarbeitet werden, indem die Interne Nachrichtenwarteschlangengröße und die In-Process-Nachrichten pro CPU für den spezifischen Host gesenkt werden.

Datenträgerkonflikte

Wenn die Datenträger überlastet sind (z. B. Datei-/MSMQ-Transporte), sollten Sie ein Upgrade auf mehrere Spindeln in Erwägung ziehen und die Datenträger mit RAID 1+0 strippen. Darüber hinaus ist es bei Verwendung des FILE-Transports wichtig, sicherzustellen, dass die Ordner (sowohl Empfangen als auch Senden) nicht zu groß werden (>50.000 Dateien).

Der Empfangsordner kann anwachsen, wenn BizTalk Server die Menge der in das System eingehenden Daten aus verschiedenen unten erläuterten Gründen einschränkt. Außerdem ist es wichtig, Daten aus dem Sendeordner zu verschieben, damit das Wachstum dieses Ordners BizTalk Server nicht daran hindert, weitere Daten zu schreiben. Bei nicht transaktionalen MSMQ-Warteschlangen empfiehlt es sich, die Empfangswarteschlangen remote zu erstellen, damit Datenträgerkonflikte auf dem BizTalk-Server verringert werden.

Diese Konfiguration (nicht transaktionale Remotewarteschlangen) bietet den zusätzlichen Vorteil der Hochverfügbarkeit, da der Remoteserver, der die Warteschlange hostet, geclustert werden kann.

Weitere Systemressourcenkonflikte

Je nach der Art des konfigurierten Transports ist es unter Umständen notwendig, Systemressourcen wie IIS für HTTP/SOAP zu konfigurieren (z. B. MaxIOThreads, MaxWorkerThreads).

Downstreamengpässe

Wenn das Downstreamsystem Daten nicht schnell genug von BizTalk empfangen kann, sammeln sich diese Ausgabedaten in den BizTalk-Datenbanken an und führen zu einer Überlastung. Dadurch wird die Einschränkung ausgelöst und die Empfangspipeline verkleinert, was den Gesamtdurchsatz des BizTalk-Systems beeinträchtigt. Ein direktes Zeichen hierfür ist das Spoolwachstum.

Auswirkungen der Einschränkung

Eine Einschränkung wird ausgelöst, damit das System nicht in einen nicht wiederherstellbaren Status gerät. Anhand der Einschränkung lässt sich also gut feststellen, ob das System normal funktioniert und wo die Ursache des Problems liegt. Nachdem der Grund für den Engpass im Einschränkungsstatus ermittelt wurde, analysieren Sie die übrigen Leistungsindikatoren, um die Ursache des Problems genauer zu analysieren.

Eine große Anzahl von Konflikten in der MessageBox-Datenbank kann ihre Ursache z. B. in einer starken CPU-Auslastung haben, die wiederum durch exzessive Auslagerung verursacht wird, deren Ursache ein zu gering bemessener Arbeitsspeicher ist. Eine große Anzahl von Konflikten in der MessageBox-Datenbank kann auch durch eine große Zahl von Sperrkonflikten verursacht werden, deren Ursache wiederum überlastete Festplattenlaufwerke sind.

Anwendungsspezifische BizTalk-Leistungsindikatoren

Object	Instanz	Leistungsindikator	Beschreibung
BizTalk Messaging	RxHost	Dokumente empfangen/s	Eingangsrate
BizTalk Messaging	TxHost	Dokumente verarbeitet/s	Ausgangsrate
XLANG/s-Orchestrierungen	PxHost	Abgeschlossene Orchestrierungen/s	Verarbeitungsrate
BizTalk : MessageBox: Allgemeine Leistungsindikatoren	MsgBoxName	Spoolgröße	Kumulative Größe aller Hostwarteschlangen
BizTalk : MessageBox: Allgemeine Leistungsindikatoren	MsgBoxName	Nachverfolgung der Datengröße	Größe der TrackingData-Tabelle der MessageBox-Datenbank
BizTalk:MessageBox:Hostindikatoren	PxHost:MsgBoxName	Hostwarteschlange - Länge	Anzahl der Nachrichten in der jeweiligen Hostwarteschlange
BizTalk:MessageBox:Hostindikatoren	TxHost:MsgBoxName	Hostwarteschlange - Länge	Anzahl der Nachrichten in der jeweiligen Hostwarteschlange
BizTalk:Nachrichtenagent	RxHost	Datenbankgröße	Größe der Veröffentlichungswarteschlange (PxHost)
BizTalk:Nachrichtenagent	PxHost	Datenbankgröße	Größe der Veröffentlichungswarteschlange (TxHost)
BizTalk:Nachrichtenagent	HostName	Status der Nachrichtenübermittlungseinschränkung	Betrifft XLANG- und ausgehende Transporte
BizTalk:Nachrichtenagent	HostName	Nachrichtenveröffentlichungsdrosselungsstatus	Betrifft XLANG- und eingehende Transporte

Wo beginne ich?

Die Überwachung des Nachrichtenübermittlungsdrosselungsstatus und des Status der Nachrichtenveröffentlichungsdrosselung für jeden Host instance ist in der Regel ein guter Ausgangspunkt. Wenn der Wert dieser Indikatoren ungleich Null ist, ist dies ein Zeichen dafür, dass im BizTalk-System eine Einschränkung aktiv ist. Damit ist es möglich, die Ursache des Engpasses weiter zu analysieren. Beschreibungen zu den anderen Leistungsindikatoren finden Sie unter Identifizieren von Leistungsengpässen.

Aufbau von Rückständen

Wenn in einem 1-zu-1-Bereitstellungsszenario, in dem eine empfangene Nachricht zu einer verarbeiteten Nachricht führt, die Ausgangsrate nicht der Eingangsrate entspricht, kommt es an einer Stelle im System zu einem Rückstau. In einer solchen Situation kann die Spoolgröße überwacht werden.

Wenn der Spool linear wächst, kann noch genauer festgestellt werden, welche Anwendungswarteschlange für das Spoolwachstum verantwortlich ist.

Wenn keine Anwendungswarteschlange größer wird und der Spool weiter wächst, kann dies bedeuten, dass die Löschaufträge nicht ausreichend schnell erfolgen, da entweder der Agent nicht ausgeführt wird oder auf dem SQL-Server andere Systemressourcenkonflikte auftreten.

Wächst keine der Anwendungswarteschlangen, ist es wichtig, den Grund für dieses Wachstum zu diagnostizieren. Überwachen Sie die Systemressourcen auf dem System, das nicht in der Lage ist, die betreffende Anwendungswarteschlange zu leeren (z. B. die Warteschlange des Orchestrierungshosts wächst, da auf die CPU des Servers nicht zugegriffen wird). Überprüfen Sie zusätzlich die Werte des Einschränkungsindikators für die betreffende Hostinstanz.

Wenn der Übermittlungs-/Veröffentlichungsstatus ungleich null ist, überprüfen Sie den Wert, um den Grund für die Einschränkung festzustellen (z. B. Schwellenwert der Arbeitsspeicherauslastung ist überschritten, Anzahl der In-flight-Nachrichten ist zu hoch usw.).

F1-Profiler

Mithilfe von Leistungsindikatoren lässt sich der Ort eines Engpasses auf hoher Ebene rasch ermitteln. Sobald dieser eingegrenzt wurde, muss jedoch eventuell der Code genauer analysiert werden, damit die Auswirkungen dieses Problems verringert werden können. Mit dem in Visual Studio enthaltenen F1-Profiler lässt sich sehr gut feststellen, wo die meisten Codezyklen ausgeführt werden.

Symbole sind wichtig, um einen aussagekräftigeren Stapel zu erstellen (insbesondere für nicht verwalteten Code). Der F1-Profiler kann z. B. die Anzahl der Aufrufe und den Zeitraum bestimmen, den ein API-Aufruf für die Rückgabe benötigt. Wird der Stapel weiter analysiert, ist es eventuell möglich, die Ursache der hohen Wartezeit zu erkennen. Es kann sich beispielsweise um einen blockierenden Aufruf einer Datenbankabfrage oder einfach um einen Aufruf, auf ein Ereignis zu warten, handeln.

L2/L3-Cache

Die größten Vorteile (in Bezug auf Hardware) werden durch einen integrierten CPU-Cache erzielt. Ein größerer CPU-Cache erhöht die Cachetrefferquote und verringert die Notwendigkeit, Daten aus dem Arbeitsspeicher auf die Festplatte auszulagern.

Leistungsengpässe auf 64-Bit-Systemen

Es ist möglich, dass 64-Bit-Systeme scheinbar eine geringere Leistung erzielen als 32-Bit-Systeme. Hierfür sind verschiedene Gründe verantwortlich, vor allem der Arbeitsspeicher.

Die Leistung eines 32-Bit-Systems mit 2 GB Arbeitsspeicher lässt sich nicht ohne weiteres mit der Leistung eines ähnlichen 64-Bit-Systems mit 2 GB Arbeitsspeicher vergleichen. Das 64-Bit-System ist Datenträger-E/A-gebunden (geringe Datenträgerleerlaufzeit & hoher Wert für Datenträgerwarteschlangenlänge) und CPU-abhängig (maximale CPU-Auslastung & hoher Kontextwechsel). Dies liegt jedoch nicht daran, dass die Datei-E/A auf einem 64-Bit-System mehr Leistung beansprucht.

Das 64-Bit-System ist speicherintensiver (64-Bit-Adressierung), was dazu führt, dass das Betriebssystem den größten Teil des verfügbaren Arbeitsspeichers von 2 GB beansprucht. In diesem Fall verursachen die meisten anderen Vorgänge eine Auslagerung auf die Festplatte. Dies führt zu einer Belastung des Dateisubsystems. Das System belegt beim Auslagern von Daten und Code in und aus dem Arbeitsspeicher nicht nur CPU-Taktzeit, sondern wird auch durch die hohe Datenträgerwartezeit beeinträchtigt. Dies äußert sich sowohl in Form höherer Datenträgerkonflikte als auch in Form höherer CPU-Beanspruchung.

Dieses Problem lässt sich durch zentrales Skalieren des Servers, durch Aufrüsten des Arbeitsspeichers (idealerweise auf 8 GB) beheben. Die Vergrößerung des Arbeitsspeichers führt jedoch zu keiner Verbesserung des Durchsatzes, falls das Problem durch unzureichenden CPU-Zugriff aufgrund von zu geringem Arbeitsspeicher verursacht wird.

Verwenden von BAM zum Ermitteln von Engpässen und Problemen aufgrund hoher Wartezeit

Wenn geringe Wartezeiten erforderlich sind, können Sie mit BAM messen, wie lange das System für die Ausführung der verschiedenen Stufen innerhalb des BizTalk-Systems braucht. Obwohl nachverfolgte Nachrichtenereignisse und Dienstdaten instance daten verwendet werden können, um den Status von Nachrichten zu debuggen und die Ursache von Problemen beim Weiterleiten von Nachrichten zu diagnostizieren, kann BAM verwendet werden, um verschiedene Punkte im Nachrichtenfluss nachzuverfolgen. Durch Erstellen eines BAM-Überwachungsprofils (Definieren einer Aktivität mit Fortsetzungen) können Sie die Wartezeit zwischen verschiedenen Teilen des Systems messen, um die aufwändigsten Stufen innerhalb des Workflowprozesses zu erfassen.

Share via