Müllsammlung in Biztalk, Was wäre die weise Annäherung?

Question

Unsere BizTalk 2006-Anwendung enthält zwei Orchestrierungen, die häufig aufgerufen werden (ca. 15 Anforderungen pro Sekunde). Wir haben mögliche Speicherlecks in unserer Anwendung identifiziert, indem wir bestimmte Throttling Threshold-Änderungen im Host vorgenommen haben. Als wir die speicherbasierte Drosselung deaktivierten, begann der Prozessspeicher sich bis auf 1400 MB zu erhöhen und danach begannen wir, die Ausnahmen für den Arbeitsspeicher zu erleben.
Wir sind gezwungen, die Host-Instanzen neu zu starten, wenn diese Situation auftritt.
Wir haben uns gefragt, ob das explizite Aufrufen von GC.Collect aus der Orchestrierung in einem solchen Fall fruchtbar ist. und was könnten die Nachteile dieses Ansatzes sein?

Danke.

Answer 1

Nicht zu wissen, Biztalk meine Antwort weiter Weg sein kann ...

Ich gehe davon aus, dass noch viele Orchestrierungsinstanzen in einem Prozess ausgeführt erhöht sich die Zeit, die für eine einzelne Orchestrierungsinstanzen in Anspruch nehmen. Wenn Sie dann die Anzahl der Orchestrierungsinstanzen erhöhen, die Sie gleichzeitig ausführen können, ist die Zeit bis zur Fertigstellung groß genug, sodass die Größe der ausgeführten Orchestrierungsinstanzen für Ihren Arbeitsspeicher zu groß ist.

Ich denke, Sie müssen Drosselung basierend auf der Anzahl der laufenden Orchestrierung Instanzen tun. Wenn Sie "Abschlussrate" mit "Anzahl der laufenden Orchestrierungsinstanzen" vergleichen, werden Sie wahrscheinlich eine große flache Zone in der Mitte der Grafik sehen. Wählen Sie Ihre Drosselung aus, um Sie in der Mitte dieser stabilen Zone zu halten.

Answer 2

Speicherüberschreitungsausnahmen treten nur auf, wenn der Garbage Collector nicht genügend Speicher freigeben konnte, um eine angeforderte Zuordnung durchzuführen. Dies kann passieren, wenn Sie ein Speicherleck haben, das in einer Garbage Collection-Plattform bedeutet, dass einige Objektreferenzen länger aufbewahrt werden, als sie benötigen. Häufige Ursachen für Lecks sind Objekte, die globale Daten (statische Variablen) enthalten, z. B. ein Singleton, ein Cache oder ein Pool, der Referenzen zu lange aufbewahrt.

Wenn Sie GC.Collect explizit aufrufen, kann der Speicher aus den gleichen Gründen wie die implizite Sammlung fehlgeschlagen. Der explit GC.Collect-Aufruf würde also nur die Orchestrierung verlangsamen.

Wenn Sie .NET-Klassen von Ihrem Orchestrierungen fordern, schlage ich vor, versuchen, das Problem zu isolieren, indem die gleichen Klassen von einer reinen .NET-Anwendung aufrufen (keine BizTalk beteiligt)

Es ist auch möglich, dass es kein Leck ist, aber dass jede Instanz gleichzeitig zu viel Speicher verbraucht. BizTalk kann Orchestrierungen in der Regel dehydrieren, wenn dies erforderlich ist. Dies kann jedoch verhindert werden, wenn ein Schritt in der Orchestrierung (oder einem großen atomaren Bereich) zu lange dauert, um ausgeführt zu werden.

1400 MB sieht auch groß für nur 15 gleichzeitige Instanzen. Machst du Manipulationen an großen Nachrichten in der Orchestrierung? In diesem Fall können Sie die Speichernutzung erheblich reduzieren, indem Sie Operationen vermeiden, die das Laden der gesamten Nachricht erzwingen, und stattdessen die Nachricht mithilfe von Streaming bearbeiten.

Answer 3

Ich stimme dem obigen Plakat zu. Der Versuch, den Speicher zu löschen oder die Host-Instanz zurückzusetzen, ist nicht die Lösung, sondern nur ein Hilfsmittel. Sie müssen herausfinden, wo Sie Speicher verlieren. Ich würde mir die ganze Anwendung und nicht nur die Orchestrierung ansehen; Es ist möglich, dass die Ports auch Ihren Speicherverlust verursachen. Verwenden Sie benutzerdefinierte Funktoide in Ihren Karten? Wie wäre es mit Inline-Code? Benutzerdefinierte xslt? Ich würde auch benutzerdefinierte Pipelines betrachten, wenn Sie sie verwenden. Wenn es möglich ist, würde ich versuchen, die verschiedenen Komponenten zu isolieren und sie einzeln unter Stress- und Volumenprüfungen zu setzen; irgendwie denke ich nicht, dass ihre Orchestrierung selbst das Problem ist, sondern eher eine Karte oder eine benutzerdefinierte Komponente.

Answer 4

Doing eine Garbage Collect wird nicht frei Speicher geleakt werden, da es immer noch (irrtümlicherweise) von Ihrer Anwendung referenziert wird. Sie würden GC.Collect nur aufrufen, wenn Sie viele kurzlebige Objekte erzeugt hätten und wussten, dass Sie an einem guten Punkt waren, um sie zu befreien.

Sie müssen den undichten Code identifizieren und beheben!

Answer 5

Ich stimme dem, was der andere gesagt hat, vollkommen zu - Sie sollten sich ansehen, wo Ihr Leck ist, und es reparieren; Den GC direkt anzurufen wird Ihnen nicht helfen und ist in jedem Fall sehr unwahrscheinlich, dass es ein vernünftiger Weg ist.

Ich würde hinzufügen, dass die Drosselung existiert, um Ihre Umgebung vor dem Anhalten zu schützen, sollten Sie einen plötzlichen Anstieg des Ressourcenverbrauchs feststellen; ohne Einschränkung ist es für BizTalk (wie jeder andere Server) möglich, einen Punkt zu erreichen, an dem es nicht weiterarbeiten kann und effektiv "hängenbleibt"; Throttling ermöglicht es, langsamer zu werden, um sicherzustellen, dass die Verarbeitung noch stattfindet, bis der Ressourcenverbrauch (hoffentlich) wieder auf normales Niveau zurückkehrt;

Aus diesem Grund würde ich auch vorschlagen, dass Sie eine Drosselung für Ihre Umgebung konfiguriert haben, deren Werte angepasst werden müssten, um Ihrem Szenario zu entsprechen