Wir haben einen BizTalk-Server (einen virtuellen Server (1!) ...) in unserem Unternehmen und einen SQL-Server, auf dem die Daten gespeichert werden. Jetzt haben wir viel Datenverkehr. Ich rede von Hunderttausenden. Ich bin also nicht einmal sicher, ob ein Server wirklich sicher ist, aber unser Unternehmen ist nicht so einfach zu überzeugen.
Jetzt haben wir in letzter Zeit viele Probleme.
Erlauben Sie mir, im Detail zu situieren, damit mir nichts fehlt:
Unser Server hat 5 Anwendungen:
Unsere Probleme sind aufgetreten, seit wir die Anwendungen mit den 47 Orchestrierungen bereitgestellt haben. Viele dieser Orchestrierungen verwenden Formen zuweisen, die c # -Code für das Mapping verwenden. Dies liegt daran, dass wir HL7-Erweiterungen verwenden, und das ist etwas Besonderes, so dass wir c # code & amp; Xpath war es viel einfacher, das Mapping zu tun, da viele dieser Schemas gleich aussehen. Das c # liest XmlNodes ein, die über Xpath empfangen wurden, und gibt XmlNode zurück, die wiederum BizTalk-Nachrichten zugewiesen werden. Ich bin mir nicht sicher, ob das der Grund sein könnte, aber ich dachte, ich würde es erwähnen.
Die Sende- und Empfangsports haben viele verschiedene Typen: Datei, MQSeries, SQL, MLLP, FTP. Jeder dieser Typen hat unterschiedliche Host-Instanzen, um die Last auszugleichen. Unsere Orchestrierungen verwenden den BiztalkApplication-Host.
Auf diesem Server laufen auch ein paar Skripte, meist ftp upload scripts & amp; auch ein Zipper-Skript, das Dateien jede halbe Stunde in einer täglichen Zip-Datei komprimiert und die Zip-Dateien nach einem Monat löscht. Wir verwenden dieses ZIPScript für unsere Backup-Dateien (wir sichern viel, Backups sind auch auf unserem Server), wir haben dies getan, weil der Server Probleme mit dem Senden von Dateien an einen Ort hatte, an dem es sehr viele Dateien gab, also danach Die Dateien wurden auf Reißverschlüsse reduziert, es ging besser.
Die Probleme, die wir in letzter Zeit haben, sind hauptsächlich zwei Hauptprobleme:
Wir haben festgestellt, dass nach dem Neustart unserer Host-Instanzen die Instanznummer wieder schnell gesunken ist. Wir haben also versucht, verschiedene Host-Instanzen selektiv neu zu starten, um das Problem zu lokalisieren. Wir haben festgestellt, dass ein Neustart der Sende- / Empfangs-Host-Instanz der Datei den Zweck erfüllen würde. Also dachten wir, Dateisendungen wären das Problem. Angesichts der Tatsache, dass wir viele Backups machen. Daher haben wir die Dateitypsicherungen durch mqseries-Sicherungen ersetzt. Das gleiche Problem ist aufgetreten, und lustige Sache, Neustart der Datei senden / empfangen Host behebt das Problem immer noch.
In der Ereignisanzeige können keine Fehler gefunden werden.
In der Ereignisanzeige haben wir die folgenden Fehler bemerkt (dies sind mehrere):
Der Empfangsort "MdnBericht SQL" mit der URL "SQL: // ZNACDBPEG / mdnd0001 /" wird heruntergefahren. Details: "Die Fehlerschwelle wurde überschritten. Der Empfangsort wird heruntergefahren.".
Die Messaging Engine konnte keinen Empfangsspeicherort "M2m Othello Export Start Bestand" mit der URL "\ m2mservices \ Othello_import $ \ DataFilter Start * .xml" zum Adapter "FILE" hinzufügen. Grund: "Der FILE-Adapter kann nicht auf den Ordner \ m2mservices \ Othello_import $ \ DataFilter Start zugreifen. Stellen Sie sicher, dass dieser Ordner existiert. Fehler: Anmeldefehler: unbekannter Benutzername oder falsches Passwort. ".
Der FILE-Adapter kann nicht auf den Ordner \ m2mservices \ Othello_import $ \ DataFilter Start zugreifen. Stellen Sie sicher, dass dieser Ordner existiert. Fehler: Anmeldefehler: unbekannter Benutzername oder falsches Passwort.
Der Versuch, eine Verbindung mit der SQL Server-Datenbank "BizTalkMsgBoxDb" auf dem Server "ZNACDBBTS" herzustellen, ist fehlgeschlagen. Fehler: "Anmeldung für Benutzer fehlgeschlagen." Der Benutzer ist keiner vertrauenswürdigen SQL Server-Verbindung zugeordnet."
Es würde scheinen, dass es zu diesem Zeitpunkt einen Login-Fehler gibt und dass deswegen auch andere Dienste Probleme haben, und schließlich werden sie heruntergefahren.
Die Sache ist, unser Benutzer ist Admin, und es ist unmöglich, dass das Passwort "manchmal" falsch ist. Wir denken, dass das Problem auf ein Infrastrukturproblem zurückzuführen sein könnte, aber das ist nicht wirklich Abteilung.
Ich weiß, dass es ein langer Post ist, aber wir sind nicht mehr sicher, was wir tun sollen. Würde das Hinzufügen eines anderen Servers und das Ausgleichen der Last unsere Probleme lösen? Gibt es eine Möglichkeit, unser Gleichgewicht zu messen und zu wissen, wo wir anfangen zu spalten? Wie lauten die normalen Ladezahlen?
Ich freue mich über jede Antwort, denn diese Probleme werden schlimmer und wir haben auch eine Frist.
Vielen Dank für die Antworten!
Ihr unmittelbares Problem ist BizTalk Drosselung Feature . Es soll BizTalk helfen, vorübergehende Überlastungsbedingungen zu überleben. Eines der vielen Probleme ist, dass Sie den Throttling-Kick-in nur im Performance-Monitor und nicht im Ereignisprotokoll sehen können.
Was Sie tun sollten:
Aktualisieren für Kommentar: Sie haben genügend Host-Instanzen. Also ignoriere diesen Rat. Sie können die Anwendungen zwischen den Instanzen neu anordnen. Aber dafür gibt es keine klaren Richtlinien. So ist es nur Mischen und Raten Über die Sicherheit der Deaktivierungsdrosselung. Diese Funktion ist in vielen Szenarien nicht sinnvoll. Du musst es studieren. Überprüfen Sie, welchen der Throttling-Parameter Sie treffen (dies wird im Performance-Monitor angezeigt) und entscheiden Sie, wie Sie die Schwellenwerte ändern.
Wie viele Host-Instanzen haben Sie?
Aus der Zeile:
Die Sende- und Empfangsports haben eine Menge verschiedener Typen: Datei, MQSeries, SQL, MLLP, FTP. Jeder dieser Typen habe eine andere Host-Instanzen, um die Last ausgleichen. Unser Orchestrierungen benutzen das BiztalkApplication-Host
Es klingt, als ob Sie viel haben - Ich habe kürzlich ein System überprüft, in dem BizTalk selbst drosselte und das Problem teilweise auf zu viele Host-Instanzen zurückzuführen war. Jede Host-Instanz belastet die BizTalk-Nachrichtenbox und kaut mindestens 200 MB Arbeitsspeicher.
Wenn Sie Ihren Kommentar lesen, haben Sie 20 - das ist zu viel und wäre ein großer Teil Ihrer Probleme.
Ein gutes Start-Host-Setup wäre:
Sie können dann auch Dinge wie die Einführung von "Echtzeit" -Hosts und Batch-Hosts in Betracht ziehen, sodass Sie die Echtzeit-Hosts für niedrige Latenzzeiten optimieren können.
Sie können auch Hosts für bestimmte Anwendungen haben, wenn bekannt ist, dass sie instabil sind, aber das sollte im Allgemeinen nicht geschehen.
Ich führe ein BizTalk-System aus, das ähnliche Probleme hat und sich mit dem, was Sie sehen, einfühlen kann. Ich weiß nicht, ob es gleich ist, aber ich dachte, ich würde meine Erfahrung mit anderen teilen.
Auf die gleiche Weise scheint das Neustarten des Sende / Empfangs das Problem zu beheben. In meinem Fall fand ich eine direkte Korrelation zur Speichernutzung durch die Host-Prozesse. Ich habe Leistungsindikatoren verwendet, um zu sehen, wann ein bestimmter Host für den Speicher gedrosselt wurde. Durch das Erstellen zusätzlicher Hosts und das Verschieben von Orchestrierungen und Ports zwischen ihnen konnte ich eingrenzen, welche Business-Sets das Problem verursachten. In meinem Fall war das Neustarten der Hosts das Äquivalent zur ultimativen "Garbage Collection", um Speicher freizugeben. Das war natürlich, bis genug Instanzen kamen, um es wieder zu verschlingen.
Ich fürchte, ich habe das Problem noch nicht gelöst, aber ein paar Dinge, die ich gefunden habe, um das Problem zu lindern:
Ich mißme alle paar Minuten in perfmon, um festzustellen, wo das Problem liegt:
BizTalk: MessageAgent (*) \ Prozessspeicherauslastung (MB)
BizTalk: MessageAgent (*) \ Schwellenwert für Prozessspeicherauslastung
Speicher \ Verfügbare MBytes
Ein paar andere Dinge, die man sich ansehen sollte. Stellen Sie sicher, dass alle benutzerdefinierten Pipelines gute BizTalk-Speicherpraktiken verwenden (d. H. Keine XML-DOM-Manipulation, die sich irgendwo versteckt, usw.). Theoretisch sollte auch die Anzahl der Threads für einen bestimmten Host verringert werden, um die Menge an Speicher zu reduzieren, die es gleichzeitig erfassen kann. Mit diesem schien ich nicht viel Glück zu haben. Vielleicht hat die BizTalk-Drosselung es übertrieben, wie andere erwähnt haben, ich weiß es nicht. Wenn Sie die Perfmon-Ergebnisse an einen CSV ablegen, können Sie mit Excel einige Diagramme zur Speicherbelegung erstellen. Dies könnte nützlich sein, um mit dem Management über den Kauf von mehr Hardware zu sprechen. Angenommen, Ihr Problem passt auch in dieses Szenario.
Wir haben das Problem vorübergehend aufgrund einer Kombination aller Antworten behoben.
Wir haben die Parameter für die Verwendung des Prozessspeichers zur Verwendung bei einigen Hosts höher gesetzt.
Wir haben das Gleichgewicht der Host-Instanzen besser aufgeteilt, nachdem ich die gesamte Speicherauslastung aller Hosts analysiert habe, dank Leistungsindikatoren und auch mit dem Tool MsgBoxViewer.
Und jetzt versuchen wir mehr physischen Speicher zu bekommen & amp; hoffentlich auch ein extra Server oder ein 64bit Server.
Danke für alle Antworten!
Wir haben kürzlich einen 64-Bit-Server im Cluster mit unserem älteren Server installiert. Dadurch können wir das Gedächtnis noch besser ausbalancieren, was viele Probleme gelöst hat.
Obwohl das 64-bit uns nicht viele Verbesserungen gab (außer etwas mehr Speicher), da es keine 64-Bits auf IBM MQs, MLLPs, HL7-Pipelines usw. verwenden kann ...
Die anderen Antworten sind hilfreich für die Laufzeitoptimierung, aber ich würde auch eine Designänderung empfehlen.
Sie sagen, dass Sie in den Nachrichtenzuordnungsformen in der Orchestrierung viel Nachrichtenmanipulation durchführen.
Ich würde empfehlen, diesen Code in dedizierte Transformationen zu verschieben. Sie sind viel leichter und können schneller ausgeführt werden. Sie können benutzerdefinierte xslt und c# in diesen Karten kombinieren, um die harte Arbeit zu erledigen. Orchestrierungen kosten bei der Entwicklung, beim Design und beim Testen mehr und in der Laufzeit viel mehr.
Sie können dann Transformationen für die Nachrichtenumwandlung verwenden und das Orchestrieren (was nach dem Verschieben des Nachrichtenzuweisungscodes übrig bleibt) den Orchestrierungen überlassen.
Der zusätzliche Vorteil der Verwendung von Transformationen über Orchestrierungen besteht darin, dass sie wesentlich überprüfbarer sind.
Tags und Links sql-server c# xpath load-balancing biztalk
